date:20200131

On Thu, Jan 30, 2020 at 02:28:30PM +0100, Kevin Kofler wrote:
> Daniel P. Berrangé wrote:
> > Ignoring low bugs also probably isn't a viable stragegy
> > for EPEL, because that's a long life distro stream, and
> > so won't automatically get low CVE fixes via a rebase
> > in 6 months like we do in Fedora.  So the CVE mountain
> > is even bigger for EPEL, and also more serious due to its
> > long lifecycle.
> 
> Given that RHEL completely ignores low-impact security issues, I do not see 
> why EPEL should be held to a higher standard than RHEL itself.

I didn't say RHEL completely ignores them.  They are not fixed
asynchronously but we do fix them in the next regular minor release.

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

unison can't be compiled in Rawhide

Previously:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RBOQEJY4QHNPDUTUU7GCNVJLNEH6JYKN/
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KQ523Z3S3VUATKU6V2NASAPGBKR5EJWC/
https://lists.fedoraproject.org/pipermail/devel/2011-September/thread.html#157495

Unison is a file synchronization tool written in OCaml.  The binary
protocol isn't compatible from one major release to the next, so to
provide compatibility with the broader ecosystem of Unison on other
Linux distros we have 3 branches of it in Fedora:

  unison213 (upstream release 2.13)
  unison227 (upstream release 2.27)
  unison240 (upstream release 2.40)

We don't package upstream releases 2.48 or 2.5x in Fedora at all.

Anyway the news is that none of these branches can be compiled with
our OCaml 4.10.0-beta-1 compiler.  For the past 5 years OCaml has been
introducing safe, immutable strings.  This has required code changes
so was introduced gradually, but the last step happens next month when
OCaml 4.10.0 final is released.  In OCaml 4.10 the -unsafe-string
option is disabled, so code must be updated to use immutable strings.

Even the upstream version of Unison has not been ported to use safe
strings (ie requiring the -unsafe-string option), never mind the older
branches that we're packaging.

I did attempt a safe string port and ... it's complicated.  The code
does a lot of byte string manipulation all over the place using its
own custom functions with four letter function names, single letter
variable names, and no comments.

(Don't believe me?  Here's the first function that would need to be
fixed:

https://github.com/bcpierce00/unison/blob/26a29f79487484b7982c85e0dc879cf7aaaf584f/src/unicode.ml#L788
 )

If we were to package Unison properly in Fedora (apart from fixing
the big mess above), I would prefer that we had a single unison
package which built multiple versioned unison subpackages.  I had
a proof of concept of this a few years ago.

It looks as if Unison will be orphaned and retired unless someone who
cares persuades upstream to move to immutable strings and backport the
same work to the older branches.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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: Fedora notifications bug: 404 Not Found

On Fri, 31 Jan 2020 at 02:47, Kevin Fenzi  wrote:

> Can you provide more info?
> Was this an irc or email message?
> or was it in the git push?

It was an email notification.
___
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: Mass rebuild reminders

On Thu, Jan 30, 2020 at 06:32:24PM -0800, Kevin Fenzi wrote:
> Just a few reminders for folks:
> 
> * If your package failed to build in the mass rebuild 
> ( https://kojipkgs.fedoraproject.org/mass-rebuild/f32-failures.html ) 
> and you want to fix it, please do so. Just do a normal commit/build
> cycle for rawhide as you normally would. It should disappear from the
> above list and no FTBFS bug will be filed. 

I'm trying to build ocaml-curl which FTBFS in the mass rebuild.

It must be built against ocaml-lwt-4.4.0-6.fc32 (ie.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1444113).

However I cannot get ocaml-curl to build against this version.  Tried
building it both in the regular way and using ‘--target f32-rebuild’,
but in both cases the buildroot picked up ocaml-lwt-4.4.0-2.fc32 which
doesn't install.

I have verified locally that I can build ocaml-curl against
ocaml-lwt-4.4.0-6.fc32 successfully.

Any ideas what to do about this?

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

Fwd: Mass rebuild reminders

2020-01-31 Thread Ben Cotton

-- Forwarded message -
From: Kevin Fenzi 
Date: Fri, Jan 31, 2020, 03:40
Subject: Mass rebuild reminders
To: 


Just a few reminders for folks:

* If your package failed to build in the mass rebuild
( https://kojipkgs.fedoraproject.org/mass-rebuild/f32-failures.html )
and you want to fix it, please do so. Just do a normal commit/build
cycle for rawhide as you normally would. It should disappear from the
above list and no FTBFS bug will be filed.

* If you want to fix something else or update a package or whatever,
just do it as normal. The script that tags the mass rebuild back in will
see a newer build and not tag in the one from the mass rebuild.

* There were some failures on s390x at the beginning of the mass
rebuild. We will try and resubmit these after the mass rebuild is
done. You're welcome to resubmit them (make sure you resubmit or do a
new build in the f32-rebuild tag, not the normal tag) also anytime. The
above link should update and they will have no FTBFS filed for them.

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
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEESz7rprBJHpbnMnrQSzew2A/7u14FAl4zkbYACgkQSzew2A/7
u173vBAAknWHCGYV+82BsubPqkRfgnfmuvuRCva4zpGLnK5O2+1TuOQUsc6T4ZSg
HjUge3piGF6h/tHcp6TxDwoiR1OluRtqDeHZpnIt7iqbjplsPLrVv6KgpHTTXtR9
29KOzUNgJVQXi3YQVgmmbiR3J2fBPlsGxCUlqJvVFaTMfjtVFLg85OeMi4Khp7n7
2sux+t1uRAa44XSTPjmOuh1H8radh5yz0rybR6s3CDw5ee2KiXfb7WIRB5NQ+2/Y
LavmiQiEhbWrYssGpR3nRhvyK+MBKbF9WerM9pyybyP02Umi0pGPhEbfCqip16U0
tJ2MamVbSh6lg4yTH5erx+sBiGO10NN5RBfIY4v69HzzFK02jH5UKdOIl7S5Yj4w
KVVEEogn1oN9dURXZzy/CP3GDf2fuZuc9ad+PwfG87cCNtdAG9kVlHRH9gWYio7t
0gjtPSNWt8oq4VlYMrEdptQz70NjGIM1WBtOcptxli8X92rQOf97gShZw7dv+444
CGi4ndzl+esg5/H7M5/hSq39fkcUEGNG+OSBI768zFpnBR6H86OOny4YR/wyOzLV
b99CigQFBd/7P1ThaEmnrbcY2euKWYkimsooviiEI+AQewEDKYOTj+yuI8MQwlGw
y/pPrbnfBZNd+mZRh85auXPKk6IhPZdd1RstD0t27qaR3TtscHA=
=gyLR
-END PGP SIGNATURE-
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-annou...@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: Mass rebuild reminders

2020-01-31 Thread Miro Hrončok


On 31. 01. 20 3:32, Kevin Fenzi wrote:

Just a few reminders for folks:

* If your package failed to build in the mass rebuild
( https://kojipkgs.fedoraproject.org/mass-rebuild/f32-failures.html )
and you want to fix it, please do so. Just do a normal commit/build
cycle for rawhide as you normally would. It should disappear from the
above list and no FTBFS bug will be filed.


If I attempt a regular build (to see if the failure was random) and it fails, 
will I still get the automated FTBFs bugzilla?


--
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: Fedora pagure confusion wrt EPEL

On Fri, 31 Jan 2020 at 00:56, Fabio Valentini  wrote:
>
>> > It seems the "support" in PkgDB was also a "lie", because BugZilla
>> > doesn't even support default assignees per-branch.
>>
>> It just worked, and when somebody opened a ticket about an EPEL package,
>> the EPEL-specific maintainer became the assignee _by default_. Whether
>> bugzilla knows a separate "default assignee" is beyond my interest,
>> unless somebody or some script reassigns tickets to me which are not of
>> my concern.
>
>
> Did you actually read what I wrote? I said "per branch maintainership" is not 
> supported, and never really was. But I explicitly wrote that you're able to 
> make a destinction between bug assignees for fedora and EPEL versions of your 
> package ...
>

You are talking in riddles then. Either bugzilla can handle different
assignees for EPEL and Fedora, or it can't. Even prior to pkgdb, we
had a list in cvs with different "package owners" for EPEL and Fedora,
and e.g. for rpmfusion I created a script that synced the data to
bugzilla, so we could create new components in bugzillla and update
them, too, simply by running a script periodically. It just worked.
EPEL package had different assignees than Fedora packages. And orphans
would be assigned to orphan owner appropriately.

> So what you want to achieve (not get bugs for EPEL component assigned to you) 
> still works today and will keep working, with UI for it on the way ...

As in the original email that starts this thread, I never signed up as
a maintainer for EPEL packages and don't want to become an assignee
(and/or "default assignee") for them either. In this mysterious pagure
webui I cannot even see what I'm assigned to and what fellow packagers
are assigned to. All I see for "claws-mail" is that there is only a
single "member", but I cannot see any data that would give hints about
what's up with the EPEL 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
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Git Forge Requirements: Please see the Community Blog

2020-01-31 Thread Vít Ondruch

Dne 30. 01. 20 v 18:45 Adam Williamson napsal(a):
> On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
>>> My point is that we have to dedicate a team to work on Pagure, I would
>>> rather have these people working on improving the infrastructure so
>>> that we don't need these heroics to happen. If we don't put people to
>>> work on Pagure it will end up being another fedora-packages, badges or
>>> FAS and in couple years it will be too difficult to do anything with
>>> it. It is not only about Pagure, for example I would love to be able
>>> to replace Bodhi with something that we don't have to maintain but it
>>> is much more difficult to find an alternative to Bodhi
>> cough cough errata cough cough
>>
>> Honestly, sometimes the disconnect between what is going on in Fedora
>> and internally in Red Hat is intriguing.
> Do you really think the entire CPE team is blissfully unaware of Errata
> Tool's existence?

I have never say that. I merely pointed out that there is disconnect
between what Fedora does and what Red Hat does internally. I see a lot
of duplication and I see a lot of lost opportunities. Bodhi vs Errata is
just one example.

The other example is that Red Hat adopted Pagure internally, so if CPE
decides to let Pagure go, that decision will impact Red Hat as well and
it somehow seems to be completely fine by everybody. If there was one
person fulltime coordinating Pagure upstream, we would save a lot of
time which was already wasted here by this discussion and we would save
all the costs of possible future migration where there will be suddenly
helping whole teams just to let later the whole migration project in
unfinished state and slowly dying.

And the another thread about Java packaging is of similar nature (not
going to details here).

Vít

>  I mean, is that really the scenario that makes the
> most sense in your head, as opposed to 'they have already considered it
> but don't find it a suitable replacement'?
>
> You might ask 'why not errata
> tool?', but it seems pretty silly to just assume that they don't even
> know it exists, or something.
___
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: Git Forge Requirements: Please see the Community Blog

2020-01-31 Thread Vít Ondruch


Dne 31. 01. 20 v 1:43 Neal Gompa napsal(a):
> On Thu, Jan 30, 2020 at 6:51 PM Randy Barlow
>  wrote:
>> On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
>>> cough cough errata cough cough
>>>
>>> Honestly, sometimes the disconnect between what is going on in Fedora
>>> and internally in Red Hat is intriguing.
>> I did think about Errata tool* a bit back when I worked on Bodhi.


Thank you for that.


>>  I
>> like the idea of sharing code on one hand, but on the other hand it is
>> pretty oriented towards workflows that are designed for a product
>> release cycle. Bodhi is designed around community feedback (and now CI
>> feedback).
>>
>> It could be interesting to hold a chat with the Errata tool developers
>> to see if there is interest in sharing tooling, but it may be a lot of
>> effort to make Errata tool flexible enough to support two pretty
>> different workflows. I'd be willing to have that conversation; I could
>> be wrong.
>>

Of course, there is a lot of business logic specific to Red Hat projects
backed into Errata, but ultimately, it does not help to anybody if
Fedora release process is using different tools then Red Hat internally.
What Red Hat does internally should be just extension to what Fedora
does. The processes used internally should be proven in Fedora first.


> Why not go the other way? Bodhi could be extended to support the
> internal product workflows.
>
>
>

In ideal world, Bodhi would be upstream project to Errata or possibly
Bodhi could be the open core of Errata. It does not really matter.


Vít

___
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: Mass rebuild reminders

2020-01-31 Thread Mohan Boddu

On Fri, Jan 31, 2020, 11:51 AM Miro Hrončok  wrote:

> On 31. 01. 20 3:32, Kevin Fenzi wrote:
> > Just a few reminders for folks:
> >
> > * If your package failed to build in the mass rebuild
> > ( https://kojipkgs.fedoraproject.org/mass-rebuild/f32-failures.html )
> > and you want to fix it, please do so. Just do a normal commit/build
> > cycle for rawhide as you normally would. It should disappear from the
> > above list and no FTBFS bug will be filed.
>
> If I attempt a regular build (to see if the failure was random) and it
> fails,
> will I still get the automated FTBFs bugzilla?
>

Yes, the script will file a FTBFS ticket if the regular build fails.

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

[Test-Announce] Fedora 32 Rawhide 20200131.n.0 nightly compose nominated for testing

2020-01-31 Thread rawhide

Announcing the creation of a new nightly release validation test event
for Fedora 32 Rawhide 20200131.n.0. Please help run some tests for this
nightly compose if you have time. For more information on nightly
release validation testing, see:
https://fedoraproject.org/wiki/QA:Release_validation_test_plan

Notable package version changes:
anaconda - 20200122.n.1: anaconda-32.20-1.fc32.src, 20200131.n.0: 
anaconda-32.21-1.fc32.src
python-blivet - 20200122.n.1: python-blivet-3.1.6-1.fc32.src, 20200131.n.0: 
python-blivet-3.2.0-1.fc32.src

Test coverage information for the current release can be seen at:
https://www.happyassassin.net/testcase_stats/32

You can see all results, find testing instructions and image download
locations, and enter results on the Summary page:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20200131.n.0_Summary

The individual test result pages are:

https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20200131.n.0_Installation
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20200131.n.0_Base
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20200131.n.0_Server
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20200131.n.0_Cloud
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20200131.n.0_Desktop
https://fedoraproject.org/wiki/Test_Results:Fedora_32_Rawhide_20200131.n.0_Security_Lab

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-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/test-annou...@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: Mass rebuild reminders

>
> It must be built against ocaml-lwt-4.4.0-6.fc32 (ie.
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1444113).
>
> However I cannot get ocaml-curl to build against this version.  Tried
> building it both in the regular way and using ‘--target f32-rebuild’,
> but in both cases the buildroot picked up ocaml-lwt-4.4.0-2.fc32 which
> doesn't install.
>
>
I have a similar problem. Rebuilding elements-alexandria with gcc10
requires an elements rpm built with gcc10, but the one picked by the
buildroot is the previous one built with gcc9.2

So elements-alexandria will not succeed until elements-5.8-5.fc32 is
available.

How should I fix this? Bump release of elements and trigger a manual
rebuild, so it is sooner there, or just wait for the tag into f32, leaving
elements-alexandria broken?
___
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: Security policy adjustments to make it easier to implement and more friendly to maintainers

2020-01-31 Thread Richard Shaw

On Thu, Jan 30, 2020 at 4:58 PM Robbie Harwood  wrote:

> Richard Shaw  writes:
>
> > Not replying to anyone in particular but to the thead as a whole...
> >
> > 1. Nothing in the packager introduction process prepares a packager
> > for what to do when they get a CVE filed against one of their
> > packages. I found the whole ordeal rather stressful.
>
> Agreed, this would be good to spell out.
>
> > 4. I'm not a C/C++ programmer
>
> Maybe I'm missing something, but why is being a C/C++ programmer
> relevant to fixing security bugs?  Are you packaging programs in a
> language you don't speak?
>

Typically (but not always) the packages with security bugs are C/C++ based,
my point is that I don't have the skillset to fix them myself.


From
>
> https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/#_deal_with_reported_bugs_in_a_timely_manner
> :
>
> It is recommended that non-coder packagers should find
> co-maintainers who are familiar with the programming language used
> by their package(s)
>
> > and certainly not a security expert. If I can find a link to a fix for
> > another distro, such as debian, I'll apply it but more often than not
> > there's nothing there when I look. I'll even file an issue upstream
> > but most of the time it's ignored.
>
> This isn't a good sign for the health of your upstreams.
>
> > 5. A of times it's for an EPEL package that's much older than the
> > current release so the fix for Fedora can't be easily applied to EPEL.
>
> This is why it's recommended to have someone on packaging who speaks the
> language you're using.
>

Great idea, but in practice?

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

[Retired] gstreamer & gstreamer-plugins-base

2020-01-31 Thread Tom Callaway

Since I've moved my last dependent package off of this old stack, I've
retired gstreamer & gstreamer-plugins-base in rawhide (again).

Before reviving these poor and tired packages, please consider the
following:

* Upstream is not maintaining this code branch anymore.
* There are significant improvements in the gstreamer0.10 branch (which is
separately packaged and maintained in Fedora)

Thanks,
Tom
___
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: [Retired] gstreamer & gstreamer-plugins-base

2020-01-31 Thread Michael Catanzaro

On Fri, Jan 31, 2020 at 8:37 am, Tom Callaway  
wrote:
* There are significant improvements in the gstreamer0.10 branch 
(which is separately packaged and maintained in Fedora)


You meant to write "gstreamer1", yes?

___
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: [Retired] gstreamer & gstreamer-plugins-base

2020-01-31 Thread Dominik 'Rathann' Mierzejewski

Hi, Tom.

On Friday, 31 January 2020 at 14:37, Tom Callaway wrote:
> Since I've moved my last dependent package off of this old stack, I've
> retired gstreamer & gstreamer-plugins-base in rawhide (again).

Hold on. I'll take these.

> Before reviving these poor and tired packages, please consider the
> following:
> 
> * Upstream is not maintaining this code branch anymore.
> * There are significant improvements in the gstreamer0.10 branch (which is
> separately packaged and maintained in Fedora)

I'm very well aware of the above, but I'm forced to use some proprietary
software that is linked against gstreamer 0.10, so I need to maintain
these until the software in question gets ported to gstreamer1.

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

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

2020-01-31 Thread Fedora compose checker

No missing expected images.

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

Failed openQA tests: 54/158 (x86_64), 1/2 (arm)

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

ID: 515128  Test: x86_64 Server-dvd-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/515128
ID: 515150  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/515150
ID: 515151  Test: x86_64 Server-dvd-iso mediakit_repoclosure
URL: https://openqa.fedoraproject.org/tests/515151
ID: 515184  Test: x86_64 KDE-live-iso install_default_upload **GATING**
URL: https://openqa.fedoraproject.org/tests/515184
ID: 515189  Test: x86_64 KDE-live-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/515189
ID: 515195  Test: x86_64 KDE-live-iso install_no_user **GATING**
URL: https://openqa.fedoraproject.org/tests/515195
ID: 515209  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/515209
ID: 515214  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/515214
ID: 515218  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/515218
ID: 515219  Test: x86_64 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/515219
ID: 515222  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/515222
ID: 515225  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/515225
ID: 515226  Test: x86_64 universal install_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/515226
ID: 515227  Test: x86_64 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/515227
ID: 515230  Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/515230
ID: 515231  Test: x86_64 universal install_blivet_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/515231
ID: 515234  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/515234
ID: 515236  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/515236
ID: 515237  Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/515237
ID: 515239  Test: x86_64 universal install_blivet_btrfs
URL: https://openqa.fedoraproject.org/tests/515239
ID: 515240  Test: x86_64 universal install_blivet_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/515240
ID: 515241  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/515241
ID: 515242  Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/515242
ID: 515244  Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/515244
ID: 515245  Test: x86_64 universal install_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/515245
ID: 515251  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/515251
ID: 515252  Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/515252
ID: 515255  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/515255
ID: 515256  Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/515256
ID: 515257  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/515257
ID: 515259  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/515259
ID: 515263  Test: x86_64 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/515263
ID: 515264  Test: x86_64 universal install_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/515264
ID: 515266  Test: x86_64 universal install_blivet_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/515266
ID: 515267  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/515267
ID: 515269  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/515269
ID: 515276  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/515276
ID: 515277  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/515277
ID: 515281  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/515281
ID: 515283  Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/515283

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

ID: 515167  Test: x86_64 Workstation-l

Re: [Retired] gstreamer & gstreamer-plugins-base

2020-01-31 Thread Michael Catanzaro

On Fri, Jan 31, 2020 at 2:47 pm, Dominik 'Rathann' Mierzejewski 
 wrote:
I'm very well aware of the above, but I'm forced to use some 
proprietary

software that is linked against gstreamer 0.10, so I need to maintain
these until the software in question gets ported to gstreamer1.


gstreamer0.10 has not received security updates -- or security 
advisories -- since... 2012? I think you should maintain these packages 
in a copr or other repo outside Fedora. FESCo is actively trying to 
remove packages with security issues from the distribution and keeping 
an ancient multimedia library around is counter to that goal.


___
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: [Retired] gstreamer & gstreamer-plugins-base

2020-01-31 Thread Dominik 'Rathann' Mierzejewski

On Friday, 31 January 2020 at 14:52, Michael Catanzaro wrote:
> On Fri, Jan 31, 2020 at 2:47 pm, Dominik 'Rathann' Mierzejewski
>  wrote:
> > I'm very well aware of the above, but I'm forced to use some proprietary
> > software that is linked against gstreamer 0.10, so I need to maintain
> > these until the software in question gets ported to gstreamer1.
> 
> gstreamer0.10 has not received security updates -- or security advisories --
> since... 2012? I think you should maintain these packages in a copr or other
> repo outside Fedora.

I don't see any bugs open against these components. I can't move them to
COPR as then RPM Fusion cannot consume them. I want to maintain them, so
why are you trying to prevent me from doing that?

> FESCo is actively trying to remove packages with security issues from
> the distribution and keeping an ancient multimedia library around is
> counter to that goal.

Are you FESCo representative now? I don't see your name on the member
list. I haven't seen any announcements from FESCo saying what you've
just wrote above, so I'm not sure where that's coming from.

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: [Retired] gstreamer & gstreamer-plugins-base

2020-01-31 Thread Julen Landa Alustiza

We don't have any problem to retire open source packages that works 
because they don't move to python 3 for example, but at the same time we 
hold dead old libraries due to proprietary software.


It looks unfair at least
___
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: [Retired] gstreamer & gstreamer-plugins-base

2020-01-31 Thread Tom Callaway

Yes, I did. Apologies.

Tom

On Fri, Jan 31, 2020 at 8:41 AM Michael Catanzaro 
wrote:

> On Fri, Jan 31, 2020 at 8:37 am, Tom Callaway 
> wrote:
> > * There are significant improvements in the gstreamer0.10 branch
> > (which is separately packaged and maintained in Fedora)
>
> You meant to write "gstreamer1", yes?
>
> ___
> 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: [Retired] gstreamer & gstreamer-plugins-base

2020-01-31 Thread Felix Schwarz


Am 31.01.20 um 15:06 schrieb Julen Landa Alustiza:
> We don't have any problem to retire open source packages that works because
> they don't move to python 3 for example, but at the same time we hold dead old
> libraries due to proprietary software.
> 
> It looks unfair at least

The main difference was/is:
- We need volunteers to to maintain packages. The Fedora Python team made
  clear they would not maintain an EOL'd Python 2 longer than they already
  committed to (e.g. F31 ships Python 2 which is EOL for a month now).

  There is a volunteer for gstreamer 0.10 but afaik there was no such offer
  for Python 2 (including the stack of Python libraries as many Fedora
  packagers do not have the time to maintain libraries on an EOL'd Python
  version).

- Fedora Policy is that we don't ship software with known (major?) security
  issues.

(Also you should not presume that shipping gstreamer 0.10 in Fedora is a
given, see Dominik's answer and Miro's attempt to clarify the security policy.)

Felix
___
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: [Retired] gstreamer & gstreamer-plugins-base

2020-01-31 Thread Michael Catanzaro

On Fri, Jan 31, 2020 at 3:01 pm, Dominik 'Rathann' Mierzejewski
wrote:
I don't see any bugs open against these components. I can't move them
to
COPR as then RPM Fusion cannot consume them. I want to maintain them,
so

why are you trying to prevent me from doing that?

Nobody is going to file bugs against gstreamer0.10 because it has been
EOL for seven years or thereabouts. Nobody is putting in the time or
effort to do that work anymore; that's what EOL means. As far as I'm
aware, Fedora is the only major distro that still ships it, yes? It's
certainly gone from Debian.

It's well-known that GStreamer is security-critical; it's a parser for
a huge number of multimedia formats, written in C, containing lots of
plugins of varying quality, none of which are sandboxed. It is
irresponsible to continue shipping it.

I understand you still need it for this proprietary software, but
Fedora is not an appropriate place to host the RPMs.

Are you FESCo representative now?

No.

I don't see your name on the member
list. I haven't seen any announcements from FESCo saying what you've
just wrote above, so I'm not sure where that's coming from.

Discussions:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/IN5GRXPY6AP5C4WNOV7GNDQ3Z5NRMTSJ/

https://pagure.io/fesco/issue/1935
https://pagure.io/fesco/issue/2333

gstreamer0.10 falls into a bit of a gap here, because the CVEs go
against the modern package.

Michael

___
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 31 Network Strangeness

2020-01-31 Thread Steve Dickson

Hello,

I've recently updated my laptop to F31. Then I was no longer
able to ssh into it. After a little debugging... it turns
out my laptop was not getting the expected ip address 
from DHCP. The reason for that was the MAC address it was
sending to dhcpd had change!!! Looking at the interfaces 

bridge0: flags=4163  mtu 1500
inet 172.31.1.175  netmask 255.255.0.0  broadcast 172.31.255.255
inet6 fe80::98f9:f0d0:4b79:cdaa  prefixlen 64  scopeid 0x20
ether 3a:00:66:8a:dd:b9  txqueuelen 1000  (Ethernet)
RX packets 259601  bytes 112149182 (106.9 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 256704  bytes 39319273 (37.4 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s31f6: flags=4163  mtu 1500
ether 8c:16:45:fe:c1:f1  txqueuelen 1000  (Ethernet)
RX packets 355186  bytes 134328851 (128.1 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 256743  bytes 40395059 (38.5 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 16  memory 0xec20-ec22  

The bridge0 interface has as different MAC that the enp0s31f6 interface.
How can that be?? Esp when the hardware address (HWADDR=8C:16:45:FE:C1:F1)
is set in the ifcfg-bridge0_slave_1.

What has changed and where is the bridge MAC address coming from???

tia,

steved.
___
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: Mass rebuild reminders

On Fri, Jan 31, 2020 at 01:44:08PM +0100, Alejandro Álvarez Ayllón wrote:
> >
> > It must be built against ocaml-lwt-4.4.0-6.fc32 (ie.
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=1444113).
> >
> > However I cannot get ocaml-curl to build against this version.  Tried
> > building it both in the regular way and using ‘--target f32-rebuild’,
> > but in both cases the buildroot picked up ocaml-lwt-4.4.0-2.fc32 which
> > doesn't install.
> >
> >
> I have a similar problem. Rebuilding elements-alexandria with gcc10
> requires an elements rpm built with gcc10, but the one picked by the
> buildroot is the previous one built with gcc9.2
> 
> So elements-alexandria will not succeed until elements-5.8-5.fc32 is
> available.
> 
> How should I fix this? Bump release of elements and trigger a manual
> rebuild, so it is sooner there, or just wait for the tag into f32, leaving
> elements-alexandria broken?

I didn't want to wait so I bumped and rebuilt ocaml-lwt and will
build the fixed ocaml-curl against it.

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

Re: Fedora 31 Network Strangeness


On 31/01/2020 14:28, Steve Dickson wrote:


I've recently updated my laptop to F31. Then I was no longer
able to ssh into it. After a little debugging... it turns
out my laptop was not getting the expected ip address
from DHCP. The reason for that was the MAC address it was
sending to dhcpd had change!!! Looking at the interfaces

bridge0: flags=4163  mtu 1500
 inet 172.31.1.175  netmask 255.255.0.0  broadcast 172.31.255.255
 inet6 fe80::98f9:f0d0:4b79:cdaa  prefixlen 64  scopeid 0x20
 ether 3a:00:66:8a:dd:b9  txqueuelen 1000  (Ethernet)
 RX packets 259601  bytes 112149182 (106.9 MiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 256704  bytes 39319273 (37.4 MiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s31f6: flags=4163  mtu 1500
 ether 8c:16:45:fe:c1:f1  txqueuelen 1000  (Ethernet)
 RX packets 355186  bytes 134328851 (128.1 MiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 256743  bytes 40395059 (38.5 MiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
 device interrupt 16  memory 0xec20-ec22

The bridge0 interface has as different MAC that the enp0s31f6 interface.
How can that be?? Esp when the hardware address (HWADDR=8C:16:45:FE:C1:F1)
is set in the ifcfg-bridge0_slave_1.


How are you managing your network? NetworkManager? systemd-networkd? The
old network rc script?

I know there was a change with systemd-networkd in a recent release so
that it now creates a unique but persistent MAC for bridges and maybe
other systems like NetworkManager have done the same?

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

Re: [Retired] gstreamer & gstreamer-plugins-base

2020-01-31 Thread Felix Schwarz


Am 31.01.20 um 15:22 schrieb Felix Schwarz:
> (Also you should not presume that shipping gstreamer 0.10 in Fedora is a
> given, see Dominik's answer and Miro's attempt to clarify the security 
> policy.)
 ^^^ Michael's answer of course

Felix
___
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: Git Forge Requirements: Please see the Community Blog

2020-01-31 Thread Michal Konecny




On 31/01/2020 12:11, Vít Ondruch wrote:

Dne 31. 01. 20 v 1:43 Neal Gompa napsal(a):

On Thu, Jan 30, 2020 at 6:51 PM Randy Barlow
 wrote:

On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:

cough cough errata cough cough

Honestly, sometimes the disconnect between what is going on in Fedora
and internally in Red Hat is intriguing.

I did think about Errata tool* a bit back when I worked on Bodhi.


Thank you for that.



  I
like the idea of sharing code on one hand, but on the other hand it is
pretty oriented towards workflows that are designed for a product
release cycle. Bodhi is designed around community feedback (and now CI
feedback).

It could be interesting to hold a chat with the Errata tool developers
to see if there is interest in sharing tooling, but it may be a lot of
effort to make Errata tool flexible enough to support two pretty
different workflows. I'd be willing to have that conversation; I could
be wrong.


Of course, there is a lot of business logic specific to Red Hat projects
backed into Errata, but ultimately, it does not help to anybody if
Fedora release process is using different tools then Red Hat internally.
What Red Hat does internally should be just extension to what Fedora
does. The processes used internally should be proven in Fedora first.
This is a very nice vision that will potentially make life of Red Hat 
and Fedora much easier. I'm not that long in the Fedora project to know, 
why Fedora and Red Hat internal tools are that different, but this idea 
doesn't sound that bad. Few questions first:

Are those internal tools open source?
Could we as Fedora community use them?
Is there any legal issue?
Is this tool in good shape?

And talking about the git forge, what is Red Hat using internally as git 
forge? And then the above questions applies.


Michal




Why not go the other way? Bodhi could be extended to support the
internal product workflows.




In ideal world, Bodhi would be upstream project to Errata or possibly
Bodhi could be the open core of Errata. It does not really matter.


Vít

___
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


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez
___
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: Fedora 31 Network Strangeness

2020-01-31 Thread Steve Dickson



On 1/31/20 9:55 AM, Tom Hughes wrote:
> On 31/01/2020 14:28, Steve Dickson wrote:
> 
>> I've recently updated my laptop to F31. Then I was no longer
>> able to ssh into it. After a little debugging... it turns
>> out my laptop was not getting the expected ip address
>> from DHCP. The reason for that was the MAC address it was
>> sending to dhcpd had change!!! Looking at the interfaces
>>
>> bridge0: flags=4163  mtu 1500
>>  inet 172.31.1.175  netmask 255.255.0.0  broadcast 172.31.255.255
>>  inet6 fe80::98f9:f0d0:4b79:cdaa  prefixlen 64  scopeid 0x20
>>  ether 3a:00:66:8a:dd:b9  txqueuelen 1000  (Ethernet)
>>  RX packets 259601  bytes 112149182 (106.9 MiB)
>>  RX errors 0  dropped 0  overruns 0  frame 0
>>  TX packets 256704  bytes 39319273 (37.4 MiB)
>>  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>
>> enp0s31f6: flags=4163  mtu 1500
>>  ether 8c:16:45:fe:c1:f1  txqueuelen 1000  (Ethernet)
>>  RX packets 355186  bytes 134328851 (128.1 MiB)
>>  RX errors 0  dropped 0  overruns 0  frame 0
>>  TX packets 256743  bytes 40395059 (38.5 MiB)
>>  TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
>>  device interrupt 16  memory 0xec20-ec22
>>
>> The bridge0 interface has as different MAC that the enp0s31f6 interface.
>> How can that be?? Esp when the hardware address (HWADDR=8C:16:45:FE:C1:F1)
>> is set in the ifcfg-bridge0_slave_1.
> 
> How are you managing your network? NetworkManager? systemd-networkd? The
> old network rc script?
Using systemctl status it appears NetworkManager is active and
systemd-networkd is not so I guess NetworkManager is doing the management

> 
> I know there was a change with systemd-networkd in a recent release so
> that it now creates a unique but persistent MAC for bridges and maybe
> other systems like NetworkManager have done the same?
Hmm... this seems odd to me... any idea why this was done?

tia,

steved.
___
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: Fedora 31 Network Strangeness


On 31/01/2020 15:23, Steve Dickson wrote:


I know there was a change with systemd-networkd in a recent release so
that it now creates a unique but persistent MAC for bridges and maybe
other systems like NetworkManager have done the same?

Hmm... this seems odd to me... any idea why this was done?


I believe this is the relevant NEWS entry:

  https://github.com/systemd/systemd/blob/master/NEWS#L926

I think the idea is to ensure that a bridge always has the same
address, as by default it gets the address of whichever slave
happens to join first - that's fine in the common case where
there is one address added at boot and then others come and go
but may be non-deterministic if multiple addresses are added
at boot time.

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

Re: Fedora 31 Network Strangeness


On 31/01/2020 15:29, Tom Hughes wrote:

On 31/01/2020 15:23, Steve Dickson wrote:


I know there was a change with systemd-networkd in a recent release so
that it now creates a unique but persistent MAC for bridges and maybe
other systems like NetworkManager have done the same?

Hmm... this seems odd to me... any idea why this was done?


I believe this is the relevant NEWS entry:

   https://github.com/systemd/systemd/blob/master/NEWS#L926

I think the idea is to ensure that a bridge always has the same
address, as by default it gets the address of whichever slave
happens to join first - that's fine in the common case where
there is one address added at boot and then others come and go
but may be non-deterministic if multiple addresses are added
at boot time.


Actually thinking about it the MAC address policy comes from a
link unit so is applied by udev and isn't systemd-networkd specific.

There is an example in that NEWS entry of a link unit to turn
this off and go back to the old behaviour.

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

(ppc64le) ELF load command alignment not page-aligned

Hello all,

I am on the process of creating a new package, and making sure it builds
smoothly on Fedora.
However, even if it compiles successfully in ppc64le, the %check command
fails with this error:

/builddir/build/BUILDROOT/sourcextractor++-0.8-1.fc31.ppc64le//usr/bin/sourcextractor++:
error while loading shared libraries: libSEMain.so.0.8: ELF load command
alignment not page-aligned

I am not doing anything esoteric here, just compiling C++ the usual way.

I would rather not just add an ExcludeArch if this can be fixed, but I have
not been able to find any information on why this error may be happening.

Any suggestions?

Regards,
Alejandro

P.S The build logs:
https://kojipkgs.fedoraproject.org//work/tasks/9174/41299174/build.log
___
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: Git Forge Requirements: Please see the Community Blog

2020-01-31 Thread Neal Gompa

On Fri, Jan 31, 2020 at 10:23 AM Michal Konecny  wrote:
>
>
>
> On 31/01/2020 12:11, Vít Ondruch wrote:
> > Dne 31. 01. 20 v 1:43 Neal Gompa napsal(a):
> >> On Thu, Jan 30, 2020 at 6:51 PM Randy Barlow
> >>  wrote:
> >>> On Thu, 2020-01-30 at 10:30 +0100, Vít Ondruch wrote:
>  cough cough errata cough cough
> 
>  Honestly, sometimes the disconnect between what is going on in Fedora
>  and internally in Red Hat is intriguing.
> >>> I did think about Errata tool* a bit back when I worked on Bodhi.
> >
> > Thank you for that.
> >
> >
> >>>   I
> >>> like the idea of sharing code on one hand, but on the other hand it is
> >>> pretty oriented towards workflows that are designed for a product
> >>> release cycle. Bodhi is designed around community feedback (and now CI
> >>> feedback).
> >>>
> >>> It could be interesting to hold a chat with the Errata tool developers
> >>> to see if there is interest in sharing tooling, but it may be a lot of
> >>> effort to make Errata tool flexible enough to support two pretty
> >>> different workflows. I'd be willing to have that conversation; I could
> >>> be wrong.
> >>>
> > Of course, there is a lot of business logic specific to Red Hat projects
> > backed into Errata, but ultimately, it does not help to anybody if
> > Fedora release process is using different tools then Red Hat internally.
> > What Red Hat does internally should be just extension to what Fedora
> > does. The processes used internally should be proven in Fedora first.
> This is a very nice vision that will potentially make life of Red Hat
> and Fedora much easier. I'm not that long in the Fedora project to know,
> why Fedora and Red Hat internal tools are that different, but this idea
> doesn't sound that bad. Few questions first:
> Are those internal tools open source?
> Could we as Fedora community use them?
> Is there any legal issue?
> Is this tool in good shape?
>
> And talking about the git forge, what is Red Hat using internally as git
> forge? And then the above questions applies.
>

It was mentioned in a different part of this thread that Red Hat is
using pagure internally.


-- 
真実はいつも一つ！/ 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: epel8: BuildrootError: could not init mock buildroot

2020-01-31 Thread Stephen John Smoogen

On Thu, 30 Jan 2020 at 20:49, Kevin Fenzi  wrote:

> On Thu, Jan 30, 2020 at 07:57:22AM -0500, Stephen John Smoogen wrote:
> > On Thu, 30 Jan 2020 at 06:06, Jiri Kucera  wrote:
> > >
> > > Hello,
> > >
> > > when doing `fedpkg scratch-build --target epel8-candidate --srpm
> sox-14.4.2.0-29.el8.src.rpm`, I get:
> > >
> >
> > So there seems to be something off in koji and the repo is not getting
> > properly regenerated after the repo gets updated. These errors seem to
> > have occurred after we updated koji to the latest release so this may
> > be a change in what koji does.
>
> I fear it's just bad timing + the external rhel8 repo we have only keeps
> the newest packages (epel7 repos keep the old packages around too).
>
> koji has no way to know that an external repo updated and needs
> regeneration, so it just regenerates it when the buildroots that depend
> on it change, ie, for epel8 that means when a stable updates push goes
> out. Since updates pushes have been broken, no regen has happened
> recently. ;( For epel7, it's fine just using the older package, but in
> epel8 it's gone and you see the 404 for it.
>
> Updates pushes should be going again so that should help.
>
> After that I guess we could try and just do a regen every day no matter
> what? Or add something to the script that updates the repo to fire one
> after anything updates?
>
>
I was trying to see how to make it fire off at the end of the script but it
seemed it needed to get a kerberos ticket which I never got to figuring
out.

-- 
Stephen J Smoogen.
___
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: (ppc64le) ELF load command alignment not page-aligned

On Fri, 31 Jan 2020 16:32:15 +0100
Alejandro Álvarez Ayllón  wrote:

> Hello all,
> 
> I am on the process of creating a new package, and making sure it
> builds smoothly on Fedora.
> However, even if it compiles successfully in ppc64le, the %check
> command fails with this error:
> 
> /builddir/build/BUILDROOT/sourcextractor+
> +-0.8-1.fc31.ppc64le//usr/bin/sourcextractor++: error while loading
> shared libraries: libSEMain.so.0.8: ELF load command alignment not
> page-aligned

there could be an expectation of 4KB pages somewhere in the source
code, ppc64le runs with 64KB pages

> I am not doing anything esoteric here, just compiling C++ the usual
> way.
> 
> I would rather not just add an ExcludeArch if this can be fixed, but
> I have not been able to find any information on why this error may be
> happening.
> 
> Any suggestions?

I would open an upstream bug as a start
 
> Regards,
> Alejandro
> 
> P.S The build logs:
> https://kojipkgs.fedoraproject.org//work/tasks/9174/41299174/build.log

please link to the build task, not the log, it makes it more difficult
to get other details than necessary


Dan
___
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: [Retired] gstreamer & gstreamer-plugins-base

2020-01-31 Thread Peter Robinson

On Fri, 31 Jan 2020, 14:53 Michael Catanzaro,  wrote:

> On Fri, Jan 31, 2020 at 2:47 pm, Dominik 'Rathann' Mierzejewski
>  wrote:
> > I'm very well aware of the above, but I'm forced to use some
> > proprietary
> > software that is linked against gstreamer 0.10, so I need to maintain
> > these until the software in question gets ported to gstreamer1.
>
> gstreamer0.10 has not received security updates -- or security
> advisories -- since... 2012? I think you should maintain these packages
> in a copr or other repo outside Fedora. FESCo is actively trying to
> remove packages with security issues from the distribution and keeping
> an ancient multimedia library around is counter to that goal.
>

Agreed, I think copr is the right place for these sort of things.

Feankly if a proprietary piece of software hasn't migrated in 8+ years I
would be looking for a replacement.

>
___
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: Git Forge Requirements: Please see the Community Blog

2020-01-31 Thread Pierre-Yves Chibon

On Fri, Jan 31, 2020 at 12:11:08PM +0100, Vít Ondruch wrote:
> 
> Of course, there is a lot of business logic specific to Red Hat projects
> backed into Errata, but ultimately, it does not help to anybody if
> Fedora release process is using different tools then Red Hat internally.
> What Red Hat does internally should be just extension to what Fedora
> does. The processes used internally should be proven in Fedora first.

Welcome to our lives!
If it was mathematically possible to go above 100% that's how much agreement you
would have from us.


Pierre
___
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: (ppc64le) ELF load command alignment not page-aligned

2020-01-31 Thread Jakub Jelinek

On Fri, Jan 31, 2020 at 04:32:15PM +0100, Alejandro Álvarez Ayllón wrote:
> I am on the process of creating a new package, and making sure it builds
> smoothly on Fedora.
> However, even if it compiles successfully in ppc64le, the %check command
> fails with this error:
> 
> /builddir/build/BUILDROOT/sourcextractor++-0.8-1.fc31.ppc64le//usr/bin/sourcextractor++:
> error while loading shared libraries: libSEMain.so.0.8: ELF load command
> alignment not page-aligned

I guess you want to look at readelf -Wa libSEMain.so.0.8 and if some LOAD
segment is not 64KB aligned find out why it got there (broken linker script,
linker bug, whatever else).

Jakub
___
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: Git Forge Requirements: Please see the Community Blog

2020-01-31 Thread Rahul Sundaram

Hi

On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote:

>
> Welcome to our lives!
> If it was mathematically possible to go above 100% that's how much
> agreement you
> would have from us.
>

If Red Hat is using Pagure internally, it is really odd to discuss
replacing Pagure with something else.  The only viable replacement is
Gitlab which is a open code project written in a language that isn't a
strong fit for Fedora. Red Hat should be assigning more resources
(development & infrastructure) to add the features needed to extend Pagure
going forward and reduce the burden on the CPE team.  Has CPE leadership
considered talking internally about that?

Rahul
___
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: [security] only latest Qt 5.14.1 has all fixes

2020-01-31 Thread Rex Dieter

Damian Ivanov wrote:

>>Bumping Qt versions is... a fairly difficult process in fedora,
>>unfortunately.
> 
> Introducing a new Qt version could be very simple I think:
> 1) Branch all Qt related packages (it should be with a one line
> command or using a web interface)
> 2) Edit package version number (with a per project (like Qt:5.14.1
> project) macro - 1 digit changed/or two)
> 3) Wait for packages to be published into repo (and that repo contains
> all packages - without spec change - that use Qt priv headers).
> 4) Fix eventual build failures due to re based patches etc.
> 5) optional: Press push to start a request to get this merged into main
> repo.

Building the core Qt packages is the easy part.  We have that largely 
scripted and semi-automated.

The (much) harder part is coordinating rebuilds of all the other packages 
that depend on private Qt5 api's  (I wish there weren't so many).

-- Rex
___
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: [security] only latest Qt 5.14.1 has all fixes

2020-01-31 Thread Rex Dieter

Rex Dieter wrote:

> Damian Ivanov wrote:
> 
>>>Bumping Qt versions is... a fairly difficult process in fedora,
>>>unfortunately.
>> 
>> Introducing a new Qt version could be very simple I think:
>> 1) Branch all Qt related packages (it should be with a one line
>> command or using a web interface)
>> 2) Edit package version number (with a per project (like Qt:5.14.1
>> project) macro - 1 digit changed/or two)
>> 3) Wait for packages to be published into repo (and that repo contains
>> all packages - without spec change - that use Qt priv headers).
>> 4) Fix eventual build failures due to re based patches etc.
>> 5) optional: Press push to start a request to get this merged into main
>> repo.
> 
> Building the core Qt packages is the easy part.  We have that largely
> scripted and semi-automated.
> 
> The (much) harder part is coordinating rebuilds of all the other packages
> that depend on private Qt5 api's  (I wish there weren't so many).

I suppose I could just make it easier on myself and just use rpmdev-bumpspec 
tool on dependencies too.  Historically, I've tried to make an effort to 
keep branches merged, at least for those packages/maintainers that prefer to 
do it that way.

-- rex
___
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: Git Forge Requirements: Please see the Community Blog

2020-01-31 Thread Leigh Griffin

On Fri, Jan 31, 2020 at 3:53 PM Rahul Sundaram  wrote:

> Hi
>
> On Fri, Jan 31, 2020 at 10:46 AM Pierre-Yves Chibon wrote:
>
>>
>> Welcome to our lives!
>> If it was mathematically possible to go above 100% that's how much
>> agreement you
>> would have from us.
>>
>
> If Red Hat is using Pagure internally, it is really odd to discuss
> replacing Pagure with something else.  The only viable replacement is
> Gitlab which is a open code project written in a language that isn't a
> strong fit for Fedora. Red Hat should be assigning more resources
> (development & infrastructure) to add the features needed to extend Pagure
> going forward and reduce the burden on the CPE team.  Has CPE leadership
> considered talking internally about that?
>

This ODF is being shared internally to get requirements as well.

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


-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

lgrif...@redhat.com
M: +353877545162 IM: lgriffin
@redhatjobs    redhatjobs
 @redhatjobs


___
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: (ppc64le) ELF load command alignment not page-aligned

On Fri, 31 Jan 2020 16:43:21 +0100
Dan Horák  wrote:

> On Fri, 31 Jan 2020 16:32:15 +0100
> Alejandro Álvarez Ayllón  wrote:
> 
> > Hello all,
> > 
> > I am on the process of creating a new package, and making sure it
> > builds smoothly on Fedora.
> > However, even if it compiles successfully in ppc64le, the %check
> > command fails with this error:
> > 
> > /builddir/build/BUILDROOT/sourcextractor+
> > +-0.8-1.fc31.ppc64le//usr/bin/sourcextractor++: error while loading
> > shared libraries: libSEMain.so.0.8: ELF load command alignment not
> > page-aligned
> 
> there could be an expectation of 4KB pages somewhere in the source
> code, ppc64le runs with 64KB pages

I have reproduced this in F-30, but the question is whether this is a
new thing with newer sources or did it always happen?


Dan
___
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: Security policy adjustments to make it easier to implement and more friendly to maintainers

2020-01-31 Thread Przemek Klosowski via devel


On 1/29/20 10:09 PM, Huzaifa Sidhpurwala wrote:

Do we want to continue the same condition as described here:
https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmivehind.net%2F2020%2F01%2F28%2FFedora-has-too-many-security-bugs%2F&data=02%7C01%7Cprzemek.klosowski%40nist.gov%7C9ae214a4d4c64560672108d7a531e253%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637159505983125291&sdata=4Pejm8f%2BrbgzPlnmazM7B78%2FEURwdIX1UitDyK%2FRP3c%3D&reserved=0
For what it's worth, here's the list of most vulnerable components 
(2-digit CVE count). Of course Daniel is right that we should consider 
the severity (disregard 'low' issues perhaps)---how do you get the 
severity in addition to the 8 fields returned by the above bugzilla 
search result?


mingw-libtiff   57
xpdf    47
hdf5    40
mingw-sqlite    39
jenkins 36
asterisk    33
matio   33
kernel  31
mingw-openssl   30
LibRaw  26
nodejs  26
binutils    25
libsass 25
mingw-libxml2   25
podofo  23
mingw-jasper    22
nextcloud   22
blender 21
adplug  20
mingw-SDL2  20
sqlite  20
ImageMagick 19
exiv2   19
moodle  19
mingw-curl  18
virglrenderer   18
openjpeg    17
chromium    16
nginx   16
mingw-icu   15
xen 15
edk2    14
mingw-libxslt   13
glpi    12
imlib2  12
libdwarf    12
mingw-libgcrypt 12
mingw-libjpeg-turbo 12
mingw-webkitgtk 12
qemu    12
undertow    12
mongoose    11
python-lmdb 11
bouncycastle    10
jhead   10
libvncserver    10
mingw-expat 10
mingw-libpng    10
mingw-pcre  10
nasm    10
php 10
php-symfony 10
squirrelmail    10
wordpress   10
___
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: (ppc64le) ELF load command alignment not page-aligned

El vie., 31 ene. 2020 17:59, Dan Horák  escribió:

> On Fri, 31 Jan 2020 16:43:21 +0100
> Dan Horák  wrote:
>
> > On Fri, 31 Jan 2020 16:32:15 +0100
> > Alejandro Álvarez Ayllón  wrote:
> >
> > > Hello all,
> > >
> > > I am on the process of creating a new package, and making sure it
> > > builds smoothly on Fedora.
> > > However, even if it compiles successfully in ppc64le, the %check
> > > command fails with this error:
> > >
> > > /builddir/build/BUILDROOT/sourcextractor+
> > > +-0.8-1.fc31.ppc64le//usr/bin/sourcextractor++: error while loading
> > > shared libraries: libSEMain.so.0.8: ELF load command alignment not
> > > page-aligned
> >
> > there could be an expectation of 4KB pages somewhere in the source
> > code, ppc64le runs with 64KB pages
>
> I have reproduced this in F-30, but the question is whether this is a
> new thing with newer sources or did it always happen?
>


It is the first time I compile this software in ppc64, and probably the
first time it has been. The problem is that I do not have access to a ppc
machine to reproduce the issue. I'll try next week with qemu perhaps.


>
> Dan
> ___
> 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: Fedora pagure confusion wrt EPEL

2020-01-31 Thread Robbie Harwood

Fabio Valentini  writes:

> Michael Schwendt  wrote:
>> On Thu, 30 Jan 2020 14:44:50 +0100, Kevin Kofler wrote:
>>> Fabio Valentini wrote:
>>
>> All this would not even interest me at all, but almost a week ago
>> someone from Red Hat Security decided it would be a good idea to
>> assign to me (without asking first) ancient EPEL tickets, which are
>> almost five years (!)  old. Apparently, no proper tracking of those
>> tickets has been done for a very long time. It is entirely wrong and
>> unexpected to assign those EPEL tickets to me only because something
>> under the hood knows only a default assignee or such.
>
> For new tickets, I'd understand this. But for old tickets to get
> reassigned to you - I agree that that's weird.
>
> I wonder who the previous assignee was, and why it was decided to
> reassign now, after 5 years?

Andreas Bierfert (awjb), who was recently declared non-responsive.  So:
the assignee of the bug is not around to determine whether it can be
fixed.

I could have also needinfo(Michael) (and in hindsight I probably should
have), but based on their reaction, I don't think they would have been
any happier with that.

My view is that there's an open security bug, so it's reasonable to want
to know whether it's going to be fixed.  The assignee clearly isn't
going to answer it.  Someone responsible for another branch of the
package should be able to check trivially - and is indeed the best
person to ask, since they're the most locally knowledgeable.

In communication with Michael, I did explain that if no one was
responsible for these branches, they should retire the branches.
Michael's view in that discussion seemed to be that the problem was one
I had created, and therefore one I should fix.  (Michael can retire the
branches while I, an unrelated contributor without ProvenPackager,
cannot.)

Thanks,
--Robbie

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: (ppc64le) ELF load command alignment not page-aligned

On Fri, 31 Jan 2020 18:08:11 +0100
Alejandro Álvarez Ayllón  wrote:

> El vie., 31 ene. 2020 17:59, Dan Horák  escribió:
> 
> > On Fri, 31 Jan 2020 16:43:21 +0100
> > Dan Horák  wrote:
> >
> > > On Fri, 31 Jan 2020 16:32:15 +0100
> > > Alejandro Álvarez Ayllón  wrote:
> > >
> > > > Hello all,
> > > >
> > > > I am on the process of creating a new package, and making sure
> > > > it builds smoothly on Fedora.
> > > > However, even if it compiles successfully in ppc64le, the %check
> > > > command fails with this error:
> > > >
> > > > /builddir/build/BUILDROOT/sourcextractor+
> > > > +-0.8-1.fc31.ppc64le//usr/bin/sourcextractor++: error while
> > > > loading shared libraries: libSEMain.so.0.8: ELF load command
> > > > alignment not page-aligned
> > >
> > > there could be an expectation of 4KB pages somewhere in the source
> > > code, ppc64le runs with 64KB pages
> >
> > I have reproduced this in F-30, but the question is whether this is
> > a new thing with newer sources or did it always happen?
> >
> 
> 
> It is the first time I compile this software in ppc64, and probably
> the first time it has been. The problem is that I do not have access
> to a ppc machine to reproduce the issue. I'll try next week with qemu
> perhaps.

you can use one from
https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers

I run the command Jakub suggested and yes, there is something wrong

  Type   Offset   VirtAddr   PhysAddr   FileSiz  MemSiz 
  Flg Align
  LOAD   0x00 0x 0x 0x0488bf 
0x0488bf R E 0x1000
  LOAD   0x0494e0 0x0004d4e0 0x0004d4e0 0x002b30 
0x002c58 RW  0x1000

0x1000 isn't right, must be 0x1


Dan
___
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: (ppc64le) ELF load command alignment not page-aligned


On 31/01/2020 17:08, Alejandro Álvarez Ayllón wrote:

It is the first time I compile this software in ppc64, and probably the 
first time it has been. The problem is that I do not have access to a 
ppc machine to reproduce the issue. I'll try next week with qemu perhaps.


You can always use the test machine:

https://fedoraproject.org/wiki/Test_Machine_Resources_For_Package_Maintainers

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

Re: (ppc64le) ELF load command alignment not page-aligned

On Fri, 31 Jan 2020 18:08:11 +0100
Alejandro Álvarez Ayllón  wrote:

> El vie., 31 ene. 2020 17:59, Dan Horák  escribió:
> 
> > On Fri, 31 Jan 2020 16:43:21 +0100
> > Dan Horák  wrote:
> >
> > > On Fri, 31 Jan 2020 16:32:15 +0100
> > > Alejandro Álvarez Ayllón  wrote:
> > >
> > > > Hello all,
> > > >
> > > > I am on the process of creating a new package, and making sure
> > > > it builds smoothly on Fedora.
> > > > However, even if it compiles successfully in ppc64le, the %check
> > > > command fails with this error:
> > > >
> > > > /builddir/build/BUILDROOT/sourcextractor+
> > > > +-0.8-1.fc31.ppc64le//usr/bin/sourcextractor++: error while
> > > > loading shared libraries: libSEMain.so.0.8: ELF load command
> > > > alignment not page-aligned
> > >
> > > there could be an expectation of 4KB pages somewhere in the source
> > > code, ppc64le runs with 64KB pages
> >
> > I have reproduced this in F-30, but the question is whether this is
> > a new thing with newer sources or did it always happen?
> >
> 
> 
> It is the first time I compile this software in ppc64, and probably
> the first time it has been. The problem is that I do not have access
> to a ppc machine to reproduce the issue. I'll try next week with qemu
> perhaps.

in SourceXtractorPlusPlus-0.8/build/CMakeCache.txt

//Flags used by the linker during the creation of modules.
CMAKE_MODULE_LINKER_FLAGS:STRING=-Wl,-z,relro -Wl,--as-needed
-Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-Wl,--enable-new-dtags -Wl,--as-needed -Wl,--no-undefined  -Wl,-z,max-
page-size=0x1000

fiddling with page-size isn't good idea


Dan
___
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: (ppc64le) ELF load command alignment not page-aligned

On Fri, 31 Jan 2020 18:14:55 +0100
Dan Horák  wrote:

> On Fri, 31 Jan 2020 18:08:11 +0100
> Alejandro Álvarez Ayllón  wrote:
> 
> > El vie., 31 ene. 2020 17:59, Dan Horák  escribió:
> > 
> > > On Fri, 31 Jan 2020 16:43:21 +0100
> > > Dan Horák  wrote:
> > >
> > > > On Fri, 31 Jan 2020 16:32:15 +0100
> > > > Alejandro Álvarez Ayllón  wrote:
> > > >
> > > > > Hello all,
> > > > >
> > > > > I am on the process of creating a new package, and making sure
> > > > > it builds smoothly on Fedora.
> > > > > However, even if it compiles successfully in ppc64le, the
> > > > > %check command fails with this error:
> > > > >
> > > > > /builddir/build/BUILDROOT/sourcextractor+
> > > > > +-0.8-1.fc31.ppc64le//usr/bin/sourcextractor++: error while
> > > > > loading shared libraries: libSEMain.so.0.8: ELF load command
> > > > > alignment not page-aligned
> > > >
> > > > there could be an expectation of 4KB pages somewhere in the
> > > > source code, ppc64le runs with 64KB pages
> > >
> > > I have reproduced this in F-30, but the question is whether this
> > > is a new thing with newer sources or did it always happen?
> > >
> > 
> > 
> > It is the first time I compile this software in ppc64, and probably
> > the first time it has been. The problem is that I do not have access
> > to a ppc machine to reproduce the issue. I'll try next week with
> > qemu perhaps.
> 
> in SourceXtractorPlusPlus-0.8/build/CMakeCache.txt
> 
> //Flags used by the linker during the creation of modules.
> CMAKE_MODULE_LINKER_FLAGS:STRING=-Wl,-z,relro -Wl,--as-needed
> -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> -Wl,--enable-new-dtags -Wl,--as-needed -Wl,--no-undefined  -Wl,-z,max-
> page-size=0x1000
> 
> fiddling with page-size isn't good idea

and the problem is
in /usr/lib64/cmake/ElementsProject/ElementsBuildFlags.cmake
which is provided by elements-devel


Dan
___
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: (ppc64le) ELF load command alignment not page-aligned

El vie., 31 ene. 2020 18:21, Dan Horák  escribió:

> On Fri, 31 Jan 2020 18:14:55 +0100
> Dan Horák  wrote:
>
> > On Fri, 31 Jan 2020 18:08:11 +0100
> > Alejandro Álvarez Ayllón  wrote:
> >
> > > El vie., 31 ene. 2020 17:59, Dan Horák  escribió:
> > >
> > > > On Fri, 31 Jan 2020 16:43:21 +0100
> > > > Dan Horák  wrote:
> > > >
> > > > > On Fri, 31 Jan 2020 16:32:15 +0100
> > > > > Alejandro Álvarez Ayllón  wrote:
> > > > >
> > > > > > Hello all,
> > > > > >
> > > > > > I am on the process of creating a new package, and making sure
> > > > > > it builds smoothly on Fedora.
> > > > > > However, even if it compiles successfully in ppc64le, the
> > > > > > %check command fails with this error:
> > > > > >
> > > > > > /builddir/build/BUILDROOT/sourcextractor+
> > > > > > +-0.8-1.fc31.ppc64le//usr/bin/sourcextractor++: error while
> > > > > > loading shared libraries: libSEMain.so.0.8: ELF load command
> > > > > > alignment not page-aligned
> > > > >
> > > > > there could be an expectation of 4KB pages somewhere in the
> > > > > source code, ppc64le runs with 64KB pages
> > > >
> > > > I have reproduced this in F-30, but the question is whether this
> > > > is a new thing with newer sources or did it always happen?
> > > >
> > >
> > >
> > > It is the first time I compile this software in ppc64, and probably
> > > the first time it has been. The problem is that I do not have access
> > > to a ppc machine to reproduce the issue. I'll try next week with
> > > qemu perhaps.
> >
> > in SourceXtractorPlusPlus-0.8/build/CMakeCache.txt
> >
> > //Flags used by the linker during the creation of modules.
> > CMAKE_MODULE_LINKER_FLAGS:STRING=-Wl,-z,relro -Wl,--as-needed
> > -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
> > -Wl,--enable-new-dtags -Wl,--as-needed -Wl,--no-undefined  -Wl,-z,max-
> > page-size=0x1000
> >
> > fiddling with page-size isn't good idea
>
> and the problem is
> in /usr/lib64/cmake/ElementsProject/ElementsBuildFlags.cmake
> which is provided by elements-devel
>

Ouch, I didn't realize it insists on setting flags it should not. I'll
patch and report to upstream.

Thanks a lot for the help!

Regards,
Alejandro


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

Schedule for Mondays's FESCo Meeting (2020-02-03)

2020-01-31 Thread Fabio Valentini

Following is the list of topics that will be discussed in the
FESCo meeting on Monday, February 03 2020 at 15:00 UTC
in #fedora-meeting-1 on irc.freenode.net.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2020-02-03 15:00 UTC'

Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda


= Discussed and Voted in the Ticket =

Nonresponsive maintainer: Chris Grau (cgrau)
https://pagure.io/fesco/issue/2307
ACCEPTED (+2, 0, -0)

F33 Self-Contained Change: Retire python26
https://pagure.io/fesco/issue/2324
ACCEPTED (+3, 0, -0)

F33 Self-Contained Change: Retire python34
https://pagure.io/fesco/issue/2325
ACCEPTED (+3, 0, -0)

F32 Self-Contained Change: Provide OpenType Bitmap Fonts
https://pagure.io/fesco/issue/2327
ACCEPTED (+2, 0, -0)

Proposal: allow releng to delay the start of mass rebuilds without approval
https://pagure.io/fesco/issue/2329
ACCEPTED (+5, 0, -0)

(FTBFS) Policy exceptions for some bootloader packages
https://pagure.io/fesco/issue/2331
ACCEPTED (+4, 0, -0)

F32 Self-Contained Change: Deprecate python-nose
https://pagure.io/fesco/issue/2332
ACCEPTED (+4, 0, -0)


= Followups =

F32 System-Wide Change: Enable EarlyOOM
https://pagure.io/fesco/issue/2320
Votes in ticket sum up to (+0, 2, -1) after three weeks.


= New business =

F32 System-Wide Change: Reduce installation media size by improving
the compression ratio of SquashFS filesystem
https://pagure.io/fesco/issue/2323
Votes in ticket sum up to (+0, 0, -1) after two weeks.


= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.


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: Mass rebuild reminders

2020-01-31 Thread Jerry James

On Thu, Jan 30, 2020 at 7:39 PM Kevin Fenzi  wrote:
> * There were some failures on s390x at the beginning of the mass
> rebuild. We will try and resubmit these after the mass rebuild is
> done. You're welcome to resubmit them (make sure you resubmit or do a
> new build in the f32-rebuild tag, not the normal tag) also anytime. The
> above link should update and they will have no FTBFS filed for them.

I had some s390x-only failures later in the build cycle, all of which
had something like this in root.log:

DEBUG util.py:598:  gappalib-coq-1.4.2-5.fc32

DEBUG util.py:596:  error: unpacking of archive failed on file
/builddir/build/SOURCES/gappalib-coq-1.4.2.tar.gz;5e30d4ed: cpio: read
failed - Inappropriate ioctl for device
DEBUG util.py:596:  error:
/builddir/build/originals/gappalib-coq-1.4.2-5.fc32.src.rpm cannot be
installed

Will those also be resubmitted automatically, or should I build them
myself?  Do we know what causes that?

Regards,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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: Git Forge Requirements: Please see the Community Blog

2020-01-31 Thread Robbie Harwood

Neal Gompa  writes:

> Michal Konecny  wrote:
>> Vít Ondruch wrote:
>>> Neal Gompa napsal(a):
 Randy Barlow  wrote:
> Vít Ondruch wrote:
>
>> cough cough errata cough cough
>>
>> Honestly, sometimes the disconnect between what is going on in
>> Fedora and internally in Red Hat is intriguing.
>
> I like the idea of sharing code on one hand, but on the other hand
> it is pretty oriented towards workflows that are designed for a
> product release cycle. Bodhi is designed around community feedback
> (and now CI feedback).
>
> It could be interesting to hold a chat with the Errata tool
> developers to see if there is interest in sharing tooling, but it
> may be a lot of effort to make Errata tool flexible enough to
> support two pretty different workflows. I'd be willing to have
> that conversation; I could be wrong.
>>>
>>> Of course, there is a lot of business logic specific to Red Hat
>>> projects backed into Errata, but ultimately, it does not help to
>>> anybody if Fedora release process is using different tools then Red
>>> Hat internally.  What Red Hat does internally should be just
>>> extension to what Fedora does. The processes used internally should
>>> be proven in Fedora first.
>>
>> This is a very nice vision that will potentially make life of Red Hat
>> and Fedora much easier. I'm not that long in the Fedora project to
>> know, why Fedora and Red Hat internal tools are that different, but
>> this idea doesn't sound that bad. Few questions first: Are those
>> internal tools open source?  Could we as Fedora community use them?
>> Is there any legal issue?  Is this tool in good shape?
>>
>> And talking about the git forge, what is Red Hat using internally as
>> git forge? And then the above questions applies.
>
> It was mentioned in a different part of this thread that Red Hat is
> using pagure internally.

Using, not standardized on.  It depends on the team.

Thanks,
--Robbie


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: Mass rebuild reminders

2020-01-31 Thread Kevin Fenzi

On Fri, Jan 31, 2020 at 10:41:36AM +, Richard W.M. Jones wrote:
> On Thu, Jan 30, 2020 at 06:32:24PM -0800, Kevin Fenzi wrote:
> > Just a few reminders for folks:
> > 
> > * If your package failed to build in the mass rebuild 
> > ( https://kojipkgs.fedoraproject.org/mass-rebuild/f32-failures.html ) 
> > and you want to fix it, please do so. Just do a normal commit/build
> > cycle for rawhide as you normally would. It should disappear from the
> > above list and no FTBFS bug will be filed. 
> 
> I'm trying to build ocaml-curl which FTBFS in the mass rebuild.
> 
> It must be built against ocaml-lwt-4.4.0-6.fc32 (ie.
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1444113).
> 
> However I cannot get ocaml-curl to build against this version.  Tried
> building it both in the regular way and using ‘--target f32-rebuild’,
> but in both cases the buildroot picked up ocaml-lwt-4.4.0-2.fc32 which
> doesn't install.
> 
> I have verified locally that I can build ocaml-curl against
> ocaml-lwt-4.4.0-6.fc32 successfully.
> 
> Any ideas what to do about this?

The mass rebuild does not update the buildroot, it's using the normal
f32 one. 

If you need that package, bump and rebuild in f32 as normal, wait for it
to land in the buildroot and then bump and rebuild the dependent
package. 

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: Mass rebuild reminders

2020-01-31 Thread Kevin Fenzi

On Fri, Jan 31, 2020 at 01:44:08PM +0100, Alejandro Álvarez Ayllón wrote:
> >
> > It must be built against ocaml-lwt-4.4.0-6.fc32 (ie.
> > https://koji.fedoraproject.org/koji/buildinfo?buildID=1444113).
> >
> > However I cannot get ocaml-curl to build against this version.  Tried
> > building it both in the regular way and using ‘--target f32-rebuild’,
> > but in both cases the buildroot picked up ocaml-lwt-4.4.0-2.fc32 which
> > doesn't install.
> >
> >
> I have a similar problem. Rebuilding elements-alexandria with gcc10
> requires an elements rpm built with gcc10, but the one picked by the
> buildroot is the previous one built with gcc9.2
> 
> So elements-alexandria will not succeed until elements-5.8-5.fc32 is
> available.
> 
> How should I fix this? Bump release of elements and trigger a manual
> rebuild, so it is sooner there, or just wait for the tag into f32, leaving
> elements-alexandria broken?

Up to you. You could bump and rebuild elements now, then bump and
rebuild elements-alexandria now and be done, or wait until the mass
rebuild side tag is merged and then bump and rebuild elements-alexandria
then.

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: Mass rebuild reminders

2020-01-31 Thread Kevin Fenzi

On Fri, Jan 31, 2020 at 11:27:04AM -0700, Jerry James wrote:
> On Thu, Jan 30, 2020 at 7:39 PM Kevin Fenzi  wrote:
> > * There were some failures on s390x at the beginning of the mass
> > rebuild. We will try and resubmit these after the mass rebuild is
> > done. You're welcome to resubmit them (make sure you resubmit or do a
> > new build in the f32-rebuild tag, not the normal tag) also anytime. The
> > above link should update and they will have no FTBFS filed for them.
> 
> I had some s390x-only failures later in the build cycle, all of which
> had something like this in root.log:
> 
> DEBUG util.py:598:  gappalib-coq-1.4.2-5.fc32
> 
> DEBUG util.py:596:  error: unpacking of archive failed on file
> /builddir/build/SOURCES/gappalib-coq-1.4.2.tar.gz;5e30d4ed: cpio: read
> failed - Inappropriate ioctl for device
> DEBUG util.py:596:  error:
> /builddir/build/originals/gappalib-coq-1.4.2-5.fc32.src.rpm cannot be
> installed
> 
> Will those also be resubmitted automatically, or should I build them
> myself?  Do we know what causes that?

Hopefully we can identify them and resubmit them. But you are welcome to
do so now if you like. 

No, we don't know what cases it. It seems to happen sometimes on ZVM
s390x instances when there is a lot of load. 

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: Fedora pagure confusion wrt EPEL

On Fri, 31 Jan 2020 at 18:11, Robbie Harwood  wrote:
>
> I could have also needinfo(Michael) (and in hindsight I probably should
> have), but based on their reaction, I don't think they would have been
> any happier with that.

I would have preferred private email over assigning multiple tickets
to me and causing bugzilla spam for all the ticket changes including
(!) multiple needinfo inquiries.

> Andreas Bierfert (awjb), who was recently declared non-responsive.

That could have been mentioned.
Is that when some process transferred EPEL packages to me without prior asking?

> My view is that there's an open security bug, so it's reasonable to want
> to know whether it's going to be fixed.

You consider it reasonable to look into ancient security issues after
almost five years? The related tracking bugs did serve no purpose for
almost five years?

> Someone responsible for another branch of the
> package should be able to check trivially - and is indeed the best
> person to ask, since they're the most locally knowledgeable.

As I've pointed out in private email, with proper reporting and
tracking of those CVEs, the CVE ids would be mentioned in the spec
%changelog of the Fedora package, where typically a much newer version
is packaged. If none of those security issues has been reported for
Fedora, it should be safe to assume that the Fedora packages have not
been deemed vulnerable.

> In communication with Michael, I did explain that if no one was
> responsible for these branches, they should retire the branches.
> Michael's view in that discussion seemed to be that the problem was one
> I had created, and therefore one I should fix.  (Michael can retire the
> branches while I, an unrelated contributor without ProvenPackager,
> cannot.)

As pointed out, I don't keep an eye on EPEL. I'm completely surprised
that all of a sudden I am expected to look into EPEL packaging
matters. I still don't understand why I have become the assignee of
EPEL tickets and possibly EPEL packages, too, when I never asked for
that.
___
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: Fedora 31 Network Strangeness

2020-01-31 Thread Steve Dickson



On 1/31/20 10:31 AM, Tom Hughes wrote:
> On 31/01/2020 15:29, Tom Hughes wrote:
>> On 31/01/2020 15:23, Steve Dickson wrote:
>>
 I know there was a change with systemd-networkd in a recent release so
 that it now creates a unique but persistent MAC for bridges and maybe
 other systems like NetworkManager have done the same?
>>> Hmm... this seems odd to me... any idea why this was done?
>>
>> I believe this is the relevant NEWS entry:
>>
>>    https://github.com/systemd/systemd/blob/master/NEWS#L926
>>
>> I think the idea is to ensure that a bridge always has the same
>> address, as by default it gets the address of whichever slave
>> happens to join first - that's fine in the common case where
>> there is one address added at boot and then others come and go
>> but may be non-deterministic if multiple addresses are added
>> at boot time.
> 
> Actually thinking about it the MAC address policy comes from a
> link unit so is applied by udev and isn't systemd-networkd specific.
> 
> There is an example in that NEWS entry of a link unit to turn
> this off and go back to the old behaviour.

Thanks for the info!! 

steved.
___
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: Fedora pagure confusion wrt EPEL

2020-01-31 Thread Robbie Harwood

Michael Schwendt  writes:

> On Fri, 31 Jan 2020 at 18:11, Robbie Harwood  wrote:
>>
>> I could have also needinfo(Michael) (and in hindsight I probably
>> should have), but based on their reaction, I don't think they would
>> have been any happier with that.
>
> I would have preferred private email over assigning multiple tickets
> to me and causing bugzilla spam for all the ticket changes including
> (!) multiple needinfo inquiries.

You received a total of between 4 and 8 emails depending on how bugzilla
batched them.  My apologies for the extra 3-7.

>> Andreas Bierfert (awjb), who was recently declared non-responsive.
>
> That could have been mentioned.  Is that when some process transferred
> EPEL packages to me without prior asking?

I did mention it.  My words were that "the maintainer is no longer
active in Fedora, and you're the default assignee for the package".

Your response, by the way, was: "Would you mind becoming familiar with
the Fedora Project a bit?".

>> My view is that there's an open security bug, so it's reasonable to want
>> to know whether it's going to be fixed.
>
> You consider it reasonable to look into ancient security issues after
> almost five years?  The related tracking bugs did serve no purpose for
> almost five years?

Yes?  This shouldn't come as a surprise to you.  The whole process of
security bugs, CVEs, and the like exists to get them *fixed*.  If they
are in fact not, you might not care about EPEL, but EPEL doesn't want to
ship vulnerable software any more than you do.

>> Someone responsible for another branch of the package should be able
>> to check trivially - and is indeed the best person to ask, since
>> they're the most locally knowledgeable.
>
> As I've pointed out in private email, with proper reporting and
> tracking of those CVEs, the CVE ids would be mentioned in the spec
> %changelog of the Fedora package, where typically a much newer version
> is packaged. If none of those security issues has been reported for
> Fedora, it should be safe to assume that the Fedora packages have not
> been deemed vulnerable.

You are repeatedly ignoring that I'm not concerned about the Fedora
package.  Please stop.  You are subject mater expert for the project.
No one is better suited than you to answer the question of whether a
given version is affected or not.

>> In communication with Michael, I did explain that if no one was
>> responsible for these branches, they should retire the branches.
>> Michael's view in that discussion seemed to be that the problem was
>> one I had created, and therefore one I should fix.  (Michael can
>> retire the branches while I, an unrelated contributor without
>> ProvenPackager, cannot.)
>
> As pointed out, I don't keep an eye on EPEL. I'm completely surprised
> that all of a sudden I am expected to look into EPEL packaging
> matters. I still don't understand why I have become the assignee of
> EPEL tickets and possibly EPEL packages, too, when I never asked for
> that.

I mentioned that in my emails, and people have repeatedly explained it
to you here too.  I *also* mentioned in my email that if no one is
responsible for them to your knowledge, the proper thing to do was to
remove the branches, and provided you information on how to do so.

This isn't a silo.  We're supposed to be working together, and helping
each other.  Your responses of refusing to even consider answering
questions about EPEL, replete condescension, and refusal to actually
read what I (and others) have been saying continues to make this
difficult.  Please stop.

Thanks,
--Robbie

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

Co-Maintainers wanted for Pantheon / elementary apps (Vala / GObject / GTK+)

2020-01-31 Thread Fabio Valentini

Hi everybody,

With more responsibilities (FPC, Stewardship SIG, FESCo) and the
ever-growing number of packages I maintain, I don't have as much time
for the things I originally started my contributions to fedora with -
the Pantheon desktop and the accompanying elementary applications.

What makes things worse is that I am not particularly proficient with
Vala or C/GObject, other than including upstream patches or doing
simple backports. That means some issues are punted until upstream
projects get around to fixing them (and if these issues are only
affecting "third-party" distros like fedora, that can take a while).

Also, the fact that GNOME frequently (almost with every new major
stable release, which means with almost every fedora release) breaks
something - either subtly or not - does not help.
gnome-settings-daemon changes its DBus interfaces almost every
release. mutter makes sweeping API changes almost every release. Both
gala and the elementary LightDM greeter can't keep up with upstream
mutter, and are basically still stuck on mutter 3.28 support (which is
why there is a mutter328 compat package) ...

Overall, this results in the quality of all these packages not being
as high as I would like it to be (though it's still pretty good, all
things considered). In particular, there are some components that are
more "crashy" than the rest, and I don't have the time and skill to
get deep into debugging the issue in most cases:

- wingpanel (the panel for Pantheon); issues in individual indicators
also crash the whole app because they are just dlopen()ed
- switchboard (the settings application); issues in individual
settings panels also crash the whole app because they are just
dlopen()ed
- gala (the window manager): obviously bad if the WM crashes, though
not as bad because it's still an Xorg session
- plank (the dock); also optionally used on XFCE (I think)
- sequeler (third-party SQL client developed for Pantheon)

I would greatly appreciate if somebody who knows their GObject-fu
could help me out here.

The elementaryOS upstream developers are usually helpful and accept
patches - even for things that are not a problem on elementaryOS, so
long as they can be switched on/off with e.g. conditional compilation.
But reported issues - that only affect fedora - without attached
patches / PRs are obviously low priority for them, and often sit
untouched for months or years.

In general, I manage to keep the packages for Pantheon / elementary
projects up-to-date. Having set up "nightly" builds on COPR a few
years ago really helps to catch potential issues early.

If anybody is interested, here are some pointers:

- all packages are tracked in koschei, in the decathorpe/elementary group:
https://koschei.fedoraproject.org/groups/decathorpe/elementary

- nightly builds are done on COPR:
https://copr.fedorainfracloud.org/coprs/decathorpe/elementary-nightly/

Thanks,
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: Fedora pagure confusion wrt EPEL