[Bug 1640987] Upgrade perl-Business-ISMN to 1.201

[bugzilla]

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

Colin Macdonald  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2018-10-20 01:45:21



--- Comment #1 from Colin Macdonald  ---
https://src.fedoraproject.org/rpms/perl-Business-ISMN/c/5f430054035c994c331c375a56805f951379caf1

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

[Bug 1512848] biber-2.6-6.fc28 FTBFS: sortinithash does not match in tests

[bugzilla]

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

Colin Macdonald  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2018-10-20 01:22:31



--- Comment #4 from Colin Macdonald  ---
Re-enabled tests in
https://src.fedoraproject.org/rpms/biber/c/6ccec30e381d08d3cf965451a3a93c0fcf604d79

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

[Bug 1532636] bbiber: Unescaped left brace in regex

[bugzilla]

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

Colin Macdonald  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
 Resolution|--- |NEXTRELEASE
Last Closed||2018-10-20 01:18:52



--- Comment #2 from Colin Macdonald  ---
This is fixed for me in 2.11 which is in rawhide and will be in F29.

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

Re: Cannot find -latomic when building for epel7 aarch64

[Josh Stone]

On 10/19/18 6:19 PM, Robert-André Mauchin wrote:
> On samedi 20 octobre 2018 00:31:50 CEST Jonathan Dieter wrote:
>> I'm trying to build duperemove[1] for epel7[2], and it's building on
>> all the arches except aarch64.
>>
>> I'm BR'ing libatomic, but the error it gives in build.log[3] for
>> aarch64 is:
>> /usr/bin/ld: cannot find -latomic
>>
>> All current Fedora release builds were fine.
>>
>> I'm sure I'm missing something obvious, but does anyone have an idea
>> what's going on?
>>
> 
> libatomic is 4.8.5 like the gcc version for other arches.
> On aarch64, libatomic is 8.2.1 whereas gcc is still 4.8.5.
> Maybe this causes some issues.

For aarch64, libatomic comes from the gcc-libraries source package,
which I believe only exists to provide runtime support for devtoolset.
It does not have libatomic.so, only libatomic.so.1 and .so.1.2.0.  You
probably need to use devtoolset gcc to actually build+link it.
(Were those SCLs ever enabled for EPEL?)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Cannot find -latomic when building for epel7 aarch64

[Robert-André Mauchin]

On samedi 20 octobre 2018 00:31:50 CEST Jonathan Dieter wrote:
> I'm trying to build duperemove[1] for epel7[2], and it's building on
> all the arches except aarch64.
> 
> I'm BR'ing libatomic, but the error it gives in build.log[3] for
> aarch64 is:
> /usr/bin/ld: cannot find -latomic
> 
> All current Fedora release builds were fine.
> 
> I'm sure I'm missing something obvious, but does anyone have an idea
> what's going on?
> 

libatomic is 4.8.5 like the gcc version for other arches.
On aarch64, libatomic is 8.2.1 whereas gcc is still 4.8.5.
Maybe this causes some issues.



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

Fedora Rawhide-20181019.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 11/133 (x86_64), 2/24 (i386), 1/2 (arm)

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

ID: 298438  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/298438

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

ID: 298341  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/298341
ID: 298365  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/298365
ID: 298366  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/298366
ID: 298371  Test: x86_64 Workstation-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/298371
ID: 298381  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/298381
ID: 298384  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/298384
ID: 298385  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/298385
ID: 298387  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/298387
ID: 298390  Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/298390
ID: 298397  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/298397
ID: 298398  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/298398
ID: 298424  Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/298424
ID: 298437  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/298437

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

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

ID: 298360  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/298360
ID: 298361  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/298361
ID: 298430  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/298430
ID: 298456  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/298456
ID: 298457  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/298457
ID: 298458  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/298458

Passed openQA tests: 100/133 (x86_64), 20/24 (i386)

Skipped openQA tests: 19 of 159

Installed system changes in test x86_64 Server-boot-iso install_default: 
System load changed from 1.14 to 1.42
Previous test data: https://openqa.fedoraproject.org/tests/297740#downloads
Current test data: https://openqa.fedoraproject.org/tests/298333#downloads

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
System load changed from 1.42 to 1.22
Previous test data: https://openqa.fedoraproject.org/tests/297741#downloads
Current test data: https://openqa.fedoraproject.org/tests/298334#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
Filesystem for mount / changed from /dev/mapper/fedora-root to 
/dev/mapper/fedora_ibm--p8--kvm--03--guest--02-root
System load changed from 1.73 to 1.48
Previous test data: https://openqa.fedoraproject.org/tests/297746#downloads
Current test data: https://openqa.fedoraproject.org/tests/298339#downloads

Installed system changes in test i386 Everything-boot-iso install_default: 
System load changed from 1.09 to 0.28
Previous test data: https://openqa.fedoraproject.org/tests/297771#downloads
Current test data: https://openqa.fedoraproject.org/tests/298364#downloads

Installed system changes in test x86_64 Workstation-boot-iso install_default: 
System load changed from 2.17 to 2.71
Average CPU usage changed from 18.61904762 to 36.24285714
Previous test data: https://openqa.fedoraproject.org/tests/297784#downloads
Current test data: https://openqa.fedoraproject.org/tests/298377#downloads

Installed system changes in test x86_64 Workstation-boot-iso 
install_default@uefi: 
System load changed from 1.96 to 2.15
Used mem changed from 789 MiB to 871 MiB
Previous test data: https://openqa.fedoraproject.org/tests/297787#downloads
Current test data: https://openqa.fedoraproject.org/tests/298380#downloads

Installed system changes in test i386 Workstation-boot-iso install_default: 
System load changed from 1.03 to 0.65
Previous test data: https://openqa.fedoraproject.org/tests/297790#downloads
Current test data: https://openqa.fedoraproject.org/tests/298383#downloads

Installed system changes in test x86_64 

Fedora 29-20181018.n.1 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 5/133 (x86_64), 1/24 (i386), 1/2 (arm)

ID: 298500  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/298500
ID: 298513  Test: x86_64 Server-dvd-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/298513
ID: 298519  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/298519
ID: 298535  Test: x86_64 Workstation-live-iso 
desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/298535
ID: 298545  Test: x86_64 KDE-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/298545
ID: 298557  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/298557
ID: 298589  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/298589

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

ID: 298520  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/298520
ID: 298525  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/298525
ID: 298556  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/298556
ID: 298615  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/298615
ID: 298616  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/298616
ID: 298617  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/298617

Passed openQA tests: 124/133 (x86_64), 21/24 (i386)

Skipped openQA tests: 1 of 159
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Máirín Duffy]

Gerald, I'm the person who designed Hyperkitty's concept on a napkin on a 
shuttlebus with Luke Macken some years ago. Your characterization of it here is 
incorrect.

I say this with respect, please try to listen more than you post. Hyperkitty 
stats show you're dominating this conveesation.

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

Cannot find -latomic when building for epel7 aarch64

[Jonathan Dieter]

I'm trying to build duperemove[1] for epel7[2], and it's building on
all the arches except aarch64.

I'm BR'ing libatomic, but the error it gives in build.log[3] for
aarch64 is:
/usr/bin/ld: cannot find -latomic

All current Fedora release builds were fine.

I'm sure I'm missing something obvious, but does anyone have an idea
what's going on?

 [1] https://github.com/markfasheh/duperemove
 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=30336065
 [3] https://kojipkgs.fedoraproject.org//work/tasks/6089/30336089/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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Attention Gmail users, please turn off HTML mail

[Máirín Duffy]

> I just couldn't use it for day-to-day communication. Not necessarily any
> single thing, but lots and lots of fundamentals. How do I get a list of new
> threads? How do I get a list of threads I've read but which have new
> responses, and ideally show only the new responses? How can I mute a thread
> I don't want to be alerted on? How do I get to the next thread from the
> *bottom* of a thread I just read? How can I search... usefully at all? My
> point isn't to rag on HyperKitty, but I could definitely go on.

Please do. Neal and I are starting up an effort. I reached out to Abhilash, the 
upstream lead, last night on the devel list and he was very responsive to this 
idea. He's already created a gitlab subproject for our efforts upstream.

> I tried for a while to file suggestions and bug reports, but especially
> after the extra two years it took to even get deployed, it was *very* clear
> there were no resources for ongoing development from Red Hat, no significant
> non-RH Fedora development, and no meaningful outside development either.
> Basic things like https://gitlab.com/mailman/hyperkitty/issues/64 didn't
> even get *responses*. So, I stuck with my previous email client setup.
> 
> And the thing is, it's *not just me*. Take a look at
> 
> It is the 19th of the month. Not a single vote on our most busy mailing
> list. The same is true for every other list I looked at. People just aren't
> using this.

Matthew, the target user for Hyperkitty isn't a devel-list reader.

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

Re: Fedora should replace mailing lists with Discourse

[Ben Rosser]

On Fri, Oct 19, 2018 at 3:58 PM stan  wrote:
> On Fri, 19 Oct 2018 08:58:57 -0700
> "Gerald B. Cox"  wrote:
> > Software is a tool for me.  I don't get emotionally attached to it -
> > as some people apparently are.  It's a bit telling that
> > many people seem to be afraid that Discourse will be a success.
>
> It isn't free for people who have already a good working system to
> adopt Discourse.  They have to invest time and effort in learning,
> adapting, and helping fix the new system.  What's in it for them?  I've
> had this happen to me in the past, but I was paid by my employer for
> the time and effort.
>
> You aren't really selling Discourse, so much as trying to bludgeon
> people into going along with your opinion.  Anyone who's been around
> the block a few times knows that there are lots of fads with fabulous
> press that don't pan out.

Indeed-- this thread feels like it has deteriorated into pro-Discourse
and pro-email people sniping at each other. I am not sure how useful
continuing to say things like "And if this conversation were in
Discourse..." or "perhaps Discourse could help with that" really is
when trying to convince people who don't agree with you.

I don't know that I feel strongly one way or the other about Discourse
vs. email. What I do feel strongly about, as I wrote much earlier in
the thread, is that any plan to move something as important to the
project as email to a new system really needs to be carefully
considered. And part of that careful consideration needs to be an
honest assessment of what the negative consequences are likely to be.
I suspect the negative consequences (as many have already said) are
that it won't be possible to use Discourse as a drop-in replacement
for these mailing lists, which will break the workflows of numerous
current contributors, causing them to become less involved in
discussions and perhaps the project altogether.

It is a bit disheartening that some of those advocating the change
seem unwilling to acknowledge this, or have dismissed it as people who
aren't willing to move with the times, or as just "hyperbole".

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

Re: Fedora should replace mailing lists with Discourse

[Máirín Duffy]

Re: teenagers and timelines, I'm just addressing the specific concerns that 
were raised to me. 

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

Re: Fedora should replace mailing lists with Discourse

[Randy Barlow]

On Fri, 2018-10-19 at 13:05 -0700, Samuel Sieb wrote:
> For example, github and bugzilla work because they 
> have full email messages.  I don't have to go to the website to get
> the 
> rest of the message.

You actually can reply to the e-mails from GitHub (not sure about
Bugzilla). They do thread weirdly when you do that to a review comment
vs. replying to the review comment on the HTML, so it's a bit janky,
but it does work.


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Samuel Sieb]

On 10/19/18 8:58 AM, Gerald B. Cox wrote:
Software is a tool for me.  I don't get emotionally attached to it - as 
some people apparently are.  It's a bit telling that

many people seem to be afraid that Discourse will be a success.


I'm not emotionally attached to it, but I am somewhat afraid that 
Discourse will be a success.  Forum-type communication websites do not 
work for me personally, so if this mailing list moved to Discourse, my 
involvement could drop drastically depending on how the email 
integration works.  For example, github and bugzilla work because they 
have full email messages.  I don't have to go to the website to get the 
rest of the message.  I do have to go there in order to reply, but 
that's mostly ok.  However, most forums just send you an email saying 
there's something new on the topic with maybe a truncated bit of the 
message and I have to go to the website to figure out what's happened. 
That does not work and I have very little participation on those.


I find that email works really well.  It's easy to search, I control the 
labelling, organizing and filtering, I can back it up, I can use it 
offline, minimal data usage on my phone, and so on.  Features that just 
aren't going to work on a website-based system.

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

Re: Fedora should replace mailing lists with Discourse

[stan]

On Fri, 19 Oct 2018 08:58:57 -0700
"Gerald B. Cox"  wrote:

> On Fri, Oct 19, 2018 at 8:31 AM Chris Adams  wrote:
> 
> > Once upon a time, R P Herrold  said:  
> > > This seems very tone deaf and lacking in introspection, Matt
> > >
> > > perhaps by reading the subject line you chose to start this
> > > thread with  
> >
> > Matt didn't choose that - that subject was set by Gerald B. Cox.

Yeah, it is kind of confrontational; there's a big difference between 
'Should Fedora replace mailing lists with Discourse?'
and 'Fedora should replace mailing lists with Discourse.'

One implies a community discourse, the other implies a decision already
made.
 
> As I previously mentioned with all the top-posting, excerpts and
> hyperbole  
> interjected by others people
> get lost and run with mis-quotes - perhaps Discourse could help with
> that. ;-)
> 
> Software is a tool for me.  I don't get emotionally attached to it -
> as some people apparently are.  It's a bit telling that
> many people seem to be afraid that Discourse will be a success.

It isn't free for people who have already a good working system to
adopt Discourse.  They have to invest time and effort in learning,
adapting, and helping fix the new system.  What's in it for them?  I've
had this happen to me in the past, but I was paid by my employer for
the time and effort.

You aren't really selling Discourse, so much as trying to bludgeon
people into going along with your opinion.  Anyone who's been around
the block a few times knows that there are lots of fads with fabulous
press that don't pan out.

So, you are really gung-ho for Discourse.  What is your personal
experience of using it on a project, before and after?  Did you
actually see more engagement?  Did the process of development run
smoother than it had before?  Did new contributors join the project you
were working on?  Did experienced contributors keep contributing?  Did
it help build community spirit?  Did it make *your* life easier?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Attention Gmail users, please turn off HTML mail

[Anderson, Charles R]

On Fri, Oct 19, 2018 at 01:51:02PM -0500, Mátyás Selmeci wrote:
> On 10/17/18 2:38 PM, Anderson, Charles R wrote:
> > On Wed, Oct 17, 2018 at 02:12:37PM -0500, Bruno Wolff III wrote:
> >> On Wed, Oct 17, 2018 at 14:48:52 -0400,
> >>   "tonynel...@georgeanelson.com"  wrote:
>  ... For html only messages you would either need to reject them or 
>  rewrite them, both of which have issues.
> >>> I've used elinks to do that in an email forum I wrote. It worked better 
> >>> than doing it with, say, Beautiful Soup.
> >>
> >> That is a big risk on your list serve processor. I would want to use 
> >> something 
> >> a lot safer than elinks (or lynx) to parse unsolicited email messages. 
> >> What I 
> >> do at work is use a simple perl script, but it doesn't do a great job.
> > 
> > I use a perl script with these modules and some regexps to clean up
> > the result:
> > 
> > use HTML::Strip; use HTML::LinkExtor; use HTML::Entities
> > qw/decode_entities/; use URI::Escape qw/uri_unescape/;
> > ___
> 
> Is this Perl script available somewhere?  I'm interested in having
> something better than elinks for the times I read HTML mail in Mutt.

I put them up on github:

https://github.com/cranderson/mutt-scripts/tree/master
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Moving EPEL7 to python3.6

[Stephen John Smoogen]

Hi,

EPEL is a set of packages which work for CentOS and RHEL versions 6
and 7. In the version 7, we are currently using python34 and would
like to move this to python36. In doing so, we need help in both our
packaging rules and in updating a lot of packages to work for
python36.

First problem: Packaging rules.
Because there could be updates of python versions from 3.4 to 3.6 or
3.8, we wanted to make clear what python was used for any particular
library. This would make it so someone needing python-bottle did not
end up with one packaged with python-3.6 installed on a python-3.4
system. So we wanted the names to be more specific than python3 and
went with naming all the sub packages python34 or python36.

However, this was decided a while ago and it may not be the best
convention to use or one that the current python sig would like us to
use. I would like to get a naming convention cleared up and documented
so when we do a mass rebuild that the packages come out with either a
python3- or python36-

Second problem: When to do this update
We had been looking to do this in October, but it may make more sense
to do this in November after Fedora29 has shipped so that people can
help focus on this versus anything F29 related. It also gives us some
lead time to write blogs/magazine items. How does 2018-11-14 sound?

Third problem: Updating and rebuilding packages to work with python36

Below are the list of packages I found which were making
python34- packages currently in EPEL-7. In updating to
python36, I would like to have a combined Virtual Fedora Activity Day
where we work together on IRC. First we would get any scripts ready
and then work with release engineering to change macros in epel-macros
to point to the correct versions of python and any name changes. We
would then do a mass release bump and rebuild all the packages against
python3.6. As problems are found during that day we would make
appropriate changes and fix.

This might take 2 gos.

autowrap-0.16.0-1.el7.src.rpm
clustershell-1.8-1.el7.src.rpm
debconf-1.5.69-1.el7.src.rpm
espresso-4.0.0-1.el7.src.rpm
fedfind-4.2.0-1.el7.src.rpm
future-0.16.0-6.el7.src.rpm
jpype-0.6.3-3.el7.src.rpm
lammps-20180822-1.el7.src.rpm
lensfun-0.3.2-13.el7.src.rpm
lhapdf-6.2.1-1.el7.src.rpm
libprelude-4.1.0-2.el7.src.rpm
libpreludedb-4.1.0-1.el7.src.rpm
lxc-1.0.11-1.el7.src.rpm
netcdf4-python-1.2.7-3.el7.src.rpm
nordugrid-arc-5.4.2-9.el7.src.rpm
petsc4py-3.9.1-3.el7.src.rpm
prelude-correlator-4.1.1-3.el7.src.rpm
py4j-0.10.7-3.el7.src.rpm
pycmd-1.2-4.el7.src.rpm
pyflakes-1.3.0-2.el7.src.rpm
pylint-1.6.5-4.el7.src.rpm
pythia8-8.2.35-4.el7.src.rpm
python-PyGithub-1.39-1.el7.src.rpm
python-PyMySQL-0.8.1-1.el7.src.rpm
python-aiosmtpd-1.0-2.el7.src.rpm
python-apsw-3.7.17.r1-3.el7.src.rpm
python-arrow-0.8.0-3.el7.src.rpm
python-astroid-1.4.9-2.el7.src.rpm
python-atpublic-0.5-1.el7.src.rpm
python-attrs-17.4.0-3.el7.src.rpm
python-backports_abc-0.5-1.el7.src.rpm
python-bitarray-0.8.3-1.el7.src.rpm
python-blessed-1.14.1-2.el7.src.rpm
python-bottle-0.12.13-1.el7.src.rpm
python-breathe-4.2.0-3.el7.src.rpm
python-cached_property-1.3.0-7.el7.src.rpm
python-chai-1.1.1-4.el7.src.rpm
python-click-6.7-6.el7.src.rpm
python-clyent-1.2.2-2.el7.src.rpm
python-collada-0.4-15.el7.src.rpm
python-colorclass-2.2.0-2.el7.src.rpm
python-contextlib2-0.5.1-2.el7.src.rpm
python-cookies-2.2.1-6.el7.src.rpm
python-cov-core-1.15.0-8.el7.src.rpm
python-crypto-2.6.1-13.el7.src.rpm
python-cytoolz-0.7.5-1.el7.src.rpm
python-ddt-1.1.3-1.el7.src.rpm
python-defusedxml-0.5.0-1.el7.src.rpm
python-distutils-extra-2.39-7.el7.src.rpm
python-dockerpty-0.4.1-9.el7.src.rpm
python-docopt-0.6.2-7.el7.src.rpm
python-easyargs-0.9.4-2.el7.src.rpm
python-easygui-0.96-19.el7.src.rpm
python-ecdsa-0.13-4.el7.src.rpm
python-execnet-1.2.0-5.el7.src.rpm
python-falcon-1.4.1-1.el7.src.rpm
python-flexmock-0.10.2-4.el7.src.rpm
python-flufl-bounce-2.3-3.el7.src.rpm
python-flufl-i18n-1.1.3-3.el7.src.rpm
python-flufl-lock-2.4.1-3.el7.src.rpm
python-flufl-testing-0.4-1.el7.src.rpm
python-freezegun-0.1.19-1.el7.src.rpm
python-gammu-2.11-2.el7.src.rpm
python-hexdump-3.4-0.2.20160818hg66325cb5fed8.el7.src.rpm
python-hypothesis-3.12.0-1.el7.src.rpm
python-idstools-0.6.3-1.el7.src.rpm
python-ipython_genutils-0.1.0-7.el7.src.rpm
python-iso8601-0.1.11-7.el7.src.rpm
python-isort-4.2.5-8.el7.src.rpm
python-ivi-0.14.9-6.el7.src.rpm
python-jaydebeapi-1.1.1-1.el7.src.rpm
python-jedi-0.10.2-3.el7.src.rpm
python-jsonschema-2.5.1-3.el7.src.rpm
python-jupyter-core-4.3.0-1.el7.src.rpm
python-keyring-5.0-3.el7.src.rpm
python-lazr-config-2.1-5.el7.src.rpm
python-lazr-delegates-2.0.3-5.el7.src.rpm
python-lazr-smtptest-2.0.3-6.el7.src.rpm
python-lazy-object-proxy-1.2.2-1.el7.src.rpm
python-libdiscid-0.4.1-11.el7.src.rpm
python-llfuse-1.0-1.el7.src.rpm
python-locket-0.2.0-2.el7.src.rpm
python-lz4-0.8.2-1.el7.src.rpm
python-markdown-2.4.1-2.el7.src.rpm
python-maxminddb-1.4.0-2.el7.src.rpm
python-mccabe-0.6.1-6.el7.src.rpm
python-mimeparse-1.6.0-4.el7.src.rpm

[EPEL-devel] Moving EPEL7 to python3.6

[Stephen John Smoogen]

Hi,

EPEL is a set of packages which work for CentOS and RHEL versions 6
and 7. In the version 7, we are currently using python34 and would
like to move this to python36. In doing so, we need help in both our
packaging rules and in updating a lot of packages to work for
python36.

First problem: Packaging rules.
Because there could be updates of python versions from 3.4 to 3.6 or
3.8, we wanted to make clear what python was used for any particular
library. This would make it so someone needing python-bottle did not
end up with one packaged with python-3.6 installed on a python-3.4
system. So we wanted the names to be more specific than python3 and
went with naming all the sub packages python34 or python36.

However, this was decided a while ago and it may not be the best
convention to use or one that the current python sig would like us to
use. I would like to get a naming convention cleared up and documented
so when we do a mass rebuild that the packages come out with either a
python3- or python36-

Second problem: When to do this update
We had been looking to do this in October, but it may make more sense
to do this in November after Fedora29 has shipped so that people can
help focus on this versus anything F29 related. It also gives us some
lead time to write blogs/magazine items. How does 2018-11-14 sound?

Third problem: Updating and rebuilding packages to work with python36

Below are the list of packages I found which were making
python34- packages currently in EPEL-7. In updating to
python36, I would like to have a combined Virtual Fedora Activity Day
where we work together on IRC. First we would get any scripts ready
and then work with release engineering to change macros in epel-macros
to point to the correct versions of python and any name changes. We
would then do a mass release bump and rebuild all the packages against
python3.6. As problems are found during that day we would make
appropriate changes and fix.

This might take 2 gos.

autowrap-0.16.0-1.el7.src.rpm
clustershell-1.8-1.el7.src.rpm
debconf-1.5.69-1.el7.src.rpm
espresso-4.0.0-1.el7.src.rpm
fedfind-4.2.0-1.el7.src.rpm
future-0.16.0-6.el7.src.rpm
jpype-0.6.3-3.el7.src.rpm
lammps-20180822-1.el7.src.rpm
lensfun-0.3.2-13.el7.src.rpm
lhapdf-6.2.1-1.el7.src.rpm
libprelude-4.1.0-2.el7.src.rpm
libpreludedb-4.1.0-1.el7.src.rpm
lxc-1.0.11-1.el7.src.rpm
netcdf4-python-1.2.7-3.el7.src.rpm
nordugrid-arc-5.4.2-9.el7.src.rpm
petsc4py-3.9.1-3.el7.src.rpm
prelude-correlator-4.1.1-3.el7.src.rpm
py4j-0.10.7-3.el7.src.rpm
pycmd-1.2-4.el7.src.rpm
pyflakes-1.3.0-2.el7.src.rpm
pylint-1.6.5-4.el7.src.rpm
pythia8-8.2.35-4.el7.src.rpm
python-PyGithub-1.39-1.el7.src.rpm
python-PyMySQL-0.8.1-1.el7.src.rpm
python-aiosmtpd-1.0-2.el7.src.rpm
python-apsw-3.7.17.r1-3.el7.src.rpm
python-arrow-0.8.0-3.el7.src.rpm
python-astroid-1.4.9-2.el7.src.rpm
python-atpublic-0.5-1.el7.src.rpm
python-attrs-17.4.0-3.el7.src.rpm
python-backports_abc-0.5-1.el7.src.rpm
python-bitarray-0.8.3-1.el7.src.rpm
python-blessed-1.14.1-2.el7.src.rpm
python-bottle-0.12.13-1.el7.src.rpm
python-breathe-4.2.0-3.el7.src.rpm
python-cached_property-1.3.0-7.el7.src.rpm
python-chai-1.1.1-4.el7.src.rpm
python-click-6.7-6.el7.src.rpm
python-clyent-1.2.2-2.el7.src.rpm
python-collada-0.4-15.el7.src.rpm
python-colorclass-2.2.0-2.el7.src.rpm
python-contextlib2-0.5.1-2.el7.src.rpm
python-cookies-2.2.1-6.el7.src.rpm
python-cov-core-1.15.0-8.el7.src.rpm
python-crypto-2.6.1-13.el7.src.rpm
python-cytoolz-0.7.5-1.el7.src.rpm
python-ddt-1.1.3-1.el7.src.rpm
python-defusedxml-0.5.0-1.el7.src.rpm
python-distutils-extra-2.39-7.el7.src.rpm
python-dockerpty-0.4.1-9.el7.src.rpm
python-docopt-0.6.2-7.el7.src.rpm
python-easyargs-0.9.4-2.el7.src.rpm
python-easygui-0.96-19.el7.src.rpm
python-ecdsa-0.13-4.el7.src.rpm
python-execnet-1.2.0-5.el7.src.rpm
python-falcon-1.4.1-1.el7.src.rpm
python-flexmock-0.10.2-4.el7.src.rpm
python-flufl-bounce-2.3-3.el7.src.rpm
python-flufl-i18n-1.1.3-3.el7.src.rpm
python-flufl-lock-2.4.1-3.el7.src.rpm
python-flufl-testing-0.4-1.el7.src.rpm
python-freezegun-0.1.19-1.el7.src.rpm
python-gammu-2.11-2.el7.src.rpm
python-hexdump-3.4-0.2.20160818hg66325cb5fed8.el7.src.rpm
python-hypothesis-3.12.0-1.el7.src.rpm
python-idstools-0.6.3-1.el7.src.rpm
python-ipython_genutils-0.1.0-7.el7.src.rpm
python-iso8601-0.1.11-7.el7.src.rpm
python-isort-4.2.5-8.el7.src.rpm
python-ivi-0.14.9-6.el7.src.rpm
python-jaydebeapi-1.1.1-1.el7.src.rpm
python-jedi-0.10.2-3.el7.src.rpm
python-jsonschema-2.5.1-3.el7.src.rpm
python-jupyter-core-4.3.0-1.el7.src.rpm
python-keyring-5.0-3.el7.src.rpm
python-lazr-config-2.1-5.el7.src.rpm
python-lazr-delegates-2.0.3-5.el7.src.rpm
python-lazr-smtptest-2.0.3-6.el7.src.rpm
python-lazy-object-proxy-1.2.2-1.el7.src.rpm
python-libdiscid-0.4.1-11.el7.src.rpm
python-llfuse-1.0-1.el7.src.rpm
python-locket-0.2.0-2.el7.src.rpm
python-lz4-0.8.2-1.el7.src.rpm
python-markdown-2.4.1-2.el7.src.rpm
python-maxminddb-1.4.0-2.el7.src.rpm
python-mccabe-0.6.1-6.el7.src.rpm
python-mimeparse-1.6.0-4.el7.src.rpm

Fedora rawhide compose report: 20181019.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20181018.n.0
NEW: Fedora-Rawhide-20181019.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  2
Dropped packages:4
Upgraded packages:   207
Downgraded packages: 0

Size of added packages:  11.93 MiB
Size of dropped packages:22.78 MiB
Size of upgraded packages:   1.92 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20181018.n.0.s390x.tar.xz

= ADDED PACKAGES =
Package: Pencil2D-0.6.2-1.fc30
Summary: Animation/drawing software
RPMs:Pencil2D
Size:11.73 MiB

Package: notify-python-0.1.1-40.fc30
Summary: Python bindings for libnotify
RPMs:python2-notify
Size:209.45 KiB


= DROPPED PACKAGES =
Package: cmake-elementary-0.1.0-4.20171229.git319ec53.fc29
Summary: CMake modules shared by elementary projects
RPMs:cmake-elementary
Size:18.05 KiB

Package: pygoocanvas-0.14.1-24.fc29
Summary: GooCanvas python bindings
RPMs:pygoocanvas pygoocanvas-devel
Size:1.07 MiB

Package: python-repoze-what-1.0.9-21.fc30
Summary: Authorization for WSGI applications
RPMs:python-repoze-what-docs
Size:251.05 KiB

Package: thermostat-1.6.6-10.fc29
Summary: A monitoring and serviceability tool for OpenJDK
RPMs:thermostat thermostat-javadoc thermostat-webapp
Size:21.45 MiB


= UPGRADED PACKAGES =
Package:  anaconda-30.7-1.fc30
Old package:  anaconda-30.6-1.fc30
Summary:  Graphical system installer
RPMs: anaconda anaconda-core anaconda-dracut anaconda-gui 
anaconda-install-env-deps anaconda-tui anaconda-widgets anaconda-widgets-devel
Size: 18.09 MiB
Size change:  31.79 KiB
Changelog:
  * Thu Oct 18 2018 Martin Kolman  - 30.7-1
  - installclass: fix variant string for Atomic Host (#1640409) (dusty)
  - Remove EXPERIMENTAL label for mountpoint assignment in TUI (#1636940)
(mkolman)


Package:  annobin-8.58-1.fc30
Old package:  annobin-8.53-1.fc30
Summary:  Binary annotation plugin for GCC
RPMs: annobin
Size: 1.05 MiB
Size change:  6.87 KiB
Changelog:
  * Tue Oct 16 2018 Nick Clifton  - 8.55-1
  - Reset the (PPC64) section start symbol to 0 if its section is empty.  
(#1638251)

  * Thu Oct 18 2018 Nick Clifton  - 8.56-1
  - Skip PPC64 linker stubs created in the middle of text sections. (#1630640)

  * Thu Oct 18 2018 Nick Clifton  - 8.57-1
  - Suppress free of invalid pointer. (#1638371)

  * Thu Oct 18 2018 Nick Clifton  - 8.58-1
  - Skip PPC64 linker stubs created in the middle of text sections (again). 
(#1630640)


Package:  biber-2.11-1.fc30
Old package:  biber-2.7-3.fc29
Summary:  Command-line bibliographic manager, BibTeX replacement
RPMs: biber
Size: 295.18 KiB
Size change:  8.89 KiB
Changelog:
  * Tue Oct 16 2018 Ankur Sinha  - 2.11-1
  - Update to 2.11


Package:  clementine-1.3.1-29.fc30
Old package:  clementine-1.3.1-28.fc30
Summary:  A music player and library organizer
RPMs: clementine
Size: 29.20 MiB
Size change:  1.33 KiB
Changelog:
  * Thu Oct 18 2018 Orcan Ogetbil  
1.3.1-29
  - Fix a crash on a system that doesn't define XDG_CURRENT_DESKTOP. 
RHBZ#1639901


Package:  csdiff-1.5.0-1.fc30
Old package:  csdiff-1.4.0-5.fc30
Summary:  Non-interactive tools for processing code scan results in 
plain-text
RPMs: csdiff python3-csdiff
Size: 17.53 MiB
Size change:  739.79 KiB
Changelog:
  * Thu Oct 18 2018 Kamil Dudka  1.5.0-1
  - update to latest upstream release


Package:  csmock-2.2.0-1.fc30
Old package:  csmock-2.1.1-3.fc29
Summary:  A mock wrapper for Static Analysis tools
RPMs: csbuild csmock csmock-common csmock-plugin-bandit 
csmock-plugin-clang csmock-plugin-cppcheck csmock-plugin-pylint 
csmock-plugin-shellcheck csmock-plugin-smatch
Added RPMs:   csmock-plugin-smatch
Size: 151.20 KiB
Size change:  14.36 KiB
Changelog:
  * Thu Oct 18 2018 Kamil Dudka  2.2.0-1
  - update to latest upstream release


Package:  cswrap-1.5.0-1.fc30
Old package:  cswrap-1.4.0-4.fc29
Summary:  Generic compiler wrapper
RPMs: cswrap
Size: 1.86 MiB
Size change:  -238.93 KiB
Changelog:
  * Thu Oct 18 2018 Kamil Dudka  1.5.0-1
  - update to latest upstream


Package:  elementary-code-3.0-1.fc30
Old package:  elementary-code-2.4.1-13.20180825.gitdf6691c.fc30
Summary:  Code editor from elementary
RPMs: elementary-code elementary-code-devel
Size: 3.00 MiB
Size change:  71.32 KiB
Changelog:
  * Thu Oct 18 2018 Fabio Valentini  - 3.0-1
  - Update to version 3.0.


Package:  elementary-files-4.0-1.fc30
Old package:  elementary-files-0.3.5-9.20180826.git39b673c.fc30
Summary:  File manager from elementary
RPMs: elementary-files elementary-files-devel
Size: 5.06 MiB
Size change

Re: Attention Gmail users, please turn off HTML mail

[Mátyás Selmeci]

On 10/17/18 2:38 PM, Anderson, Charles R wrote:
> On Wed, Oct 17, 2018 at 02:12:37PM -0500, Bruno Wolff III wrote:
>> On Wed, Oct 17, 2018 at 14:48:52 -0400,
>>   "tonynel...@georgeanelson.com"  wrote:
 ... For html only messages you would either need to reject them or rewrite 
 them, both of which have issues.
>>> I've used elinks to do that in an email forum I wrote. It worked better 
>>> than doing it with, say, Beautiful Soup.
>>
>> That is a big risk on your list serve processor. I would want to use 
>> something 
>> a lot safer than elinks (or lynx) to parse unsolicited email messages. What 
>> I 
>> do at work is use a simple perl script, but it doesn't do a great job.
> 
> I use a perl script with these modules and some regexps to clean up
> the result:
> 
> use HTML::Strip; use HTML::LinkExtor; use HTML::Entities
> qw/decode_entities/; use URI::Escape qw/uri_unescape/;
> ___

Is this Perl script available somewhere?  I'm interested in having
something better than elinks for the times I read HTML mail in Mutt.

Thanks,
-Mat

-- 
Mátyás (Mat) Selmeci
Open Science Grid Software Team / Center for High-Throughput Computing
University of Wisconsin-Madison Department of Computer Sciences
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 29 compose report: 20181018.n.1 changes

[Fedora Branched Report]

OLD: Fedora-29-20181017.n.0
NEW: Fedora-29-20181018.n.1

= SUMMARY =
Added images:5
Dropped images:  1
Added packages:  0
Dropped packages:0
Upgraded packages:   4
Downgraded packages: 0

Size of added packages:  0 B
Size of dropped packages:0 B
Size of upgraded packages:   54.04 MiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   217.76 KiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: AtomicHost dvd-ostree aarch64
Path: 
AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20181018.n.1.iso
Image: Workstation raw-xz armhfp
Path: 
Workstation/armhfp/images/Fedora-Workstation-armhfp-29-20181018.n.1-sda.raw.xz
Image: Silverblue dvd-ostree x86_64
Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-29-20181018.n.1.iso
Image: AtomicHost dvd-ostree x86_64
Path: AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20181018.n.1.iso
Image: AtomicHost dvd-ostree ppc64le
Path: 
AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20181018.n.1.iso

= DROPPED IMAGES =
Image: Scientific_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-29-20181017.n.0.iso

= ADDED PACKAGES =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  fedora-release-29-1
Old package:  fedora-release-29-0.17
Summary:  Fedora release files
RPMs: fedora-release fedora-release-atomichost fedora-release-cinnamon 
fedora-release-cloud fedora-release-container fedora-release-coreos 
fedora-release-iot fedora-release-kde fedora-release-matecompiz 
fedora-release-server fedora-release-silverblue fedora-release-soas 
fedora-release-workstation fedora-release-xfce
Size: 295.28 KiB
Size change:  1.85 KiB
Changelog:
  * Sun Oct 14 2018 Mohan Boddu  29-1
  - Setup for F29 Final
  - Add DOCUMENTATION_URL to os-release


Package:  fedora-repos-29-1
Old package:  fedora-repos-29-0.9
Summary:  Fedora package repositories
RPMs: fedora-gpg-keys fedora-repos fedora-repos-rawhide
Size: 116.12 KiB
Size change:  44 B
Changelog:
  * Sun Oct 14 2018 Mohan Boddu  - 29-1
  - Setup for F29 Final


Package:  mutter-3.30.1-2.fc29
Old package:  mutter-3.30.1-1.fc29
Summary:  Window and compositing manager based on Clutter
RPMs: mutter mutter-devel mutter-tests
Size: 16.84 MiB
Size change:  -852 B
Changelog:
  * Thu Oct 11 2018 Jonas ??dahl  - 3.30.1-2
  - Fix disabled monitor when laptop lid is closed (rhbz#1638444)


Package:  selinux-policy-3.14.2-40.fc29
Old package:  selinux-policy-3.14.2-36.fc29
Summary:  SELinux policy configuration
RPMs: selinux-policy selinux-policy-devel selinux-policy-doc 
selinux-policy-minimum selinux-policy-mls selinux-policy-sandbox 
selinux-policy-targeted
Size: 36.79 MiB
Size change:  216.70 KiB
Changelog:
  * Tue Oct 09 2018 Lukas Vrabec  - 3.14.2-37
  - Allow boltd_t to be activated by init socket activation Resolves: 
rhbz#1633786
  - Allow virt_domain to read/write to virtd_t unix_stream socket because of 
new version of libvirt 4.4. BZ(1635803)
  - Update SELinux policy for libreswan based on the latest rebase 3.26
  - Fix typo in init_named_socket_activation interface

  * Sat Oct 13 2018 Lukas Vrabec  - 3.14.2-38
  - Update rpm macros for selinux policy from sources repository: 
https://github.com/fedora-selinux/selinux-policy-macros

  * Sat Oct 13 2018 Lukas Vrabec  - 3.14.2-39
  - Allow caller domains using cron_*_role to have entrypoint permission on 
system_cron_spool_t files BZ(1625645)
  - Add interface cron_system_spool_entrypoint()
  - Bolt added d-bus API for force-powering the thunderbolt controller, so 
system-dbusd needs acces to boltd pipes BZ(1637676)
  - Add interfaces for boltd SELinux module
  - Run travis CI only against Rawhide branch
  - Add dac_override capability to modemmanager_t domain BZ(1636608)
  - Allow systemd to mount boltd_var_run_t dirs BZ(1636823)
  - Run travis CI only against Rawhide branch
  - Label correctly /var/named/chroot*/dev/unrandom in bind chroot.

  * Tue Oct 16 2018 Lukas Vrabec  - 3.14.2-40
  - Allow boltd_t domain to dbus chat with fwupd_t domain BZ(1633786)



= DOWNGRADED PACKAGES =___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[R P Herrold]

On Fri, 19 Oct 2018, Chris Adams wrote:

> Once upon a time, R P Herrold  said:
> > This seems very tone deaf and lacking in introspection, Matt
> > 
> > perhaps by reading the subject line you chose to start this 
> > thread with
> 
> Matt didn't choose that - that subject was set by Gerald B. Cox.

If you say so (and I have no reason to doubt, but cannot 
confirm, so: sorry for the mis-attribution, Matt) ... at the 
URL in your email message headers is a link to:


https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KXPPKQNLJ6SZBUHKBMLB4OZY7WA77FGP/

Perma-link:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3MZCLLM47LIO6LFJC33RIFJHTIKQPFWP/#KXPPKQNLJ6SZBUHKBMLB4OZY7WA77FGP

and at that page, the link titled ' Back to the thread ' 
points into a wholly different discussion


https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3MZCLLM47LIO6LFJC33RIFJHTIKQPFWP/#KXPPKQNLJ6SZBUHKBMLB4OZY7WA77FGP

One more reason to dislike KyperKitty hashes over pipermail 

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

Re: Fwd: Re: Vagrant: can we make it show up in Software?

[Zach Villers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi - lurking on this thread but wanted to share;


> > and GCC are not? > > > > Should we keep it upon individual maintainer 
> discretion? Should
we > > somehow evaluate all the cases one by one? > > What about a
"Command Line tools for Developers" section in Software? > > > What
about non-developer tools? I’m thinking of things like ledger that I has
to help a new budget person install as they’ve only ever used Software.
> > 
For the items I've seen discussed so far, I keep thinking they mostly
belong to a package group. Could we tie in developer.fpo with the
software center by offering things like Virtualization, Python,
Container Management, etc? If we use consistent naming/branding it might
make life easier for folks who want to easily get the right tooling.

Does this have any merit?

Thanks,
Zach

#aikidouke

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEEXqo9HPGjOpNv2PIbdbUwJu/l/RcFAlvKFNAQHHphY2hAbWFp
bHVwLm5ldAAKCRB1tTAm7+X9F4eUEACRCltav6wLy4lqRZ/joh/8igCxquUUGs7o
RkaqG7NT6/t5NcTWT97lbpl43elnAFd3CIrC5AfHT+nSCKwwpMk/xs9JTUoVkbw2
vjRnKIRCD4ve2YvvKCZOUDO0JYN/IWLCHaviCNfqJAA8dYXMfhdy3rxhd3dei4ed
knhCtWfeTcG3LOotkT7KtsiTmUlTrzfgdTUil9gIccVTVf7h4llCSekdzuCucZ0T
7KjgipWthW/AlfVCxeGju5qXH3g4tbAaEyl61uFCUJXkjaexVzxvQ7avPxOAZo5d
NOgAf8YWVgkPAQLYzcv9NFmJdHdTwZqVYT4cFv0pETjA7I6o0lz9IfiPoDFhaqYy
6iNIV9ktX4EaielfK8XxKpGfELFLZwyl6iVY7JwSMkucYMuvpn6CXt2dS+oJ6nNZ
P5s6OTqGMH9mf39/ZSy7UWXbjGwzgk7U73L+ConMNUeahZyvs1jos1/IVEJyzWzH
x6G6u4pxujXfV4PSvOtkNBCgKT6nNI3+fQPWRPlV+4DYW9IDd0vza54/Aq72wQMa
FCJjXTgQo/IR4vEHI+oW7sWAWZ3cvyNsYL27lIMV49Z3G1sMakNOVdr2akT+HDck
la1RhWsG7DJrkWBzWDMj1yqNjK9X8Y2tIsS/yowZIu46VTiiN5xTnuQlQr1UBs7+
WWZ0d7YEkQ==
=uvtU
-END 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 131  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b6c663378c   
unrtf-0.21.9-8.el6
  69  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f21474267b   
condor-8.6.11-1.el6
  22  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-6bc3a525a2   
libmad-0.15.1b-26.el6


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

cscppc-1.5.0-1.el6
csdiff-1.5.0-1.el6
csmock-2.2.0-1.el6
cswrap-1.5.0-1.el6
php-getid3-1.9.16-1.el6
python-collectd_cvmfs-1.0.3-1.el6

Details about builds:



 cscppc-1.5.0-1.el6 (FEDORA-EPEL-2018-26f84a1626)
 A compiler wrapper that runs cppcheck in background

Update Information:

- update to the latest upstream release

ChangeLog:

* Thu Oct 18 2018 Kamil Dudka  1.5.0-1
- update to latest upstream release




 csdiff-1.5.0-1.el6 (FEDORA-EPEL-2018-26f84a1626)
 Non-interactive tools for processing code scan results in plain-text

Update Information:

- update to the latest upstream release

ChangeLog:

* Thu Oct 18 2018 Kamil Dudka  1.5.0-1
- update to latest upstream release




 csmock-2.2.0-1.el6 (FEDORA-EPEL-2018-26f84a1626)
 A mock wrapper for Static Analysis tools

Update Information:

- update to the latest upstream release

ChangeLog:

* Thu Oct 18 2018 Kamil Dudka  2.2.0-1
- update to latest upstream release




 cswrap-1.5.0-1.el6 (FEDORA-EPEL-2018-26f84a1626)
 Generic compiler wrapper

Update Information:

- update to the latest upstream release

ChangeLog:

* Thu Oct 18 2018 Kamil Dudka  1.5.0-1
- update to latest upstream




 php-getid3-1.9.16-1.el6 (FEDORA-EPEL-2018-3dbcf40e7d)
 The PHP media file parser

Update Information:

**Version 1.9.16**: (2018-10-17)  * bugfix (G:168) Ogg FLAC not parsed * bugfix
(G:163) invalid MP3 header error on VBR * bugfix (G:162) prevent writing
multiple ID3v2 versions * bugfix (G:161) MP3 VBR header duration * bugfix
(G:160) OggOpus duration sometimes incorrect * bugfix (G:157) quicktime GPS
invalid argument * bugfix (G:148) MPEG-2 aspect ratio * bugfix (G:147) Quicktime
fourcc codec name lookup * bugfix (G:147) Quicktime audio/video bitrate guessing
* bugfix (G:145) incompatible variable types * bugfix (G:139) Quicktime islt
subatoms >5 * bugfix (G:137) ID3v2 semi-numeric genres * bugfix (G:136) ID3v2
unsynchronised typo * bugfix (#2514) FLAC zero-byte block header * bugfix
(#2488) MIME types (FLAC, WAV, gzip) * bugfix (#2468) Quicktime video rotation *
bugfix (#2207) metaflac + attached pictures * bugfix (#2151) improved demo UNC
filename support * bugfix (#1966) fread fail when PHP memory_limit -1 * bugfix
(#1908) Quicktime rotation detection (using matrix values) * bugfix (#1908)
Quicktime "rcif" and "dscp" atoms * bugfix (#1900) demo.joinmp3 cut from end *
security: avoid disabled demo reflection * TIFF: expand list of named tags,
expose as 'tag_name' key for all entries * Quicktime: parse some GoPro-specific
data * helperapps (Windows): updated vorbiscomment.exe, metaflac.exe to v1.3.2 *
add more image formats supported by getimagesize()

ChangeLog:

* Thu Oct 18 2018 Remi Collet  - 1.9.16-1
- update to 1.9.16




 python-collectd_cvmfs-1.0.3-1.el6 (FEDORA-EPEL-2018-cfe5867e8b)
 Collectd plugin to monitor CvmFS Clients

Re: Fedora 29 compose report: 20181017.n.0 changes

[Fabio Valentini]

On Fri, Oct 19, 2018 at 6:20 PM Lokesh Mandvekar  wrote:
>
> On Thu, Oct 18, 2018 at 11:02:27PM +0200, Fabio Valentini wrote:
> > On Thu, Oct 18, 2018 at 10:02 PM Lokesh Mandvekar
> >  wrote:
> > >
> > >
> > > On Thu, Oct 18, 2018 at 06:50:51PM +0200, Fabio Valentini wrote:
> > > >
> > > > I'm confused by this podman build. Especially so with my Packaging
> > > > Committee hat on.
> > > >
> > > > - changelog message says it's version 10.1
> > > > - %{version} is 0.10.1
> > > > - github project has 0.10.1 tag, but its commit hash doesn't match
> > > > what's built here
> > > > - Release matches the (old!) pattern for a snapshot build
> > > > - Epoch is set to 1 if fedora > 28?
> > > >
> > > > Looking at the .spec file didn't help me, it's a hot mess.
> > > >
> > > > Can somebody enlighten me about:
> > > > Is this a snapshot build? Is it a stable release?
> > > > If it's a stable build, why doesn't the commit hash match up with the
> > > > appropriate tag?
> > >
> > > Should be fixed with the latest bump to v0.10.1.3 on rawhide, f29 and f28.
> > > Please let me know if something still looks off.
> >
> > The commit hash and release tag now match up, so that's better. And
> > the usage of Epoch seems to be ... more correct.
> > Everything else is either unchanged or worse (for example, the new
> > changelog entries don't match the actual version-release of the build
> > at all).
>
> Done https://bodhi.fedoraproject.org/updates/FEDORA-2018-8f0690a978 .

Thanks!

> FWIW, rawhide will always include the 'dev' string in release tag since it'll
> have daily auto rebuilds using upstream master.
>
> Let me know if anything else ..

ok, I give up now

> >
> > > Thanks,
> > > --
> > > Lokesh
> > > IRC, GitHub: lsm5
> > > GPG: 0xC7C3A0DD
> > > https://keybase.io/lsm5
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > 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://getfedora.org/code-of-conduct.html
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
> --
> Lokesh
> IRC, GitHub: lsm5
> GPG: 0xC7C3A0DD
> https://keybase.io/lsm5
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1640572] Upgrade perl-Test-PostgreSQL to 1.27

[bugzilla]

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



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

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

Re: Fedora should replace mailing lists with Discourse

[Matthew Miller]

On Fri, Oct 19, 2018 at 07:49:41AM -0700, Gerald B. Cox wrote:
> Oh really... I said that... perhaps you should take 5 seconds and read the
> subject of the thread.

Hey, let's please keep this friendly.


-- 
Matthew Miller

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

Re: Fedora should replace mailing lists with Discourse

[Simo Sorce]

On Fri, 2018-10-19 at 07:28 -0700, Gerald B. Cox wrote:
> And if this conversation were in Discourse, we could simply move it to a
> new topic ;-)

Some people see it as history rewriting ... one of the reasons I like
email is that *you* can't change stuff after the fact, because *I* have
it archived.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Matthew Miller]

On Fri, Oct 19, 2018 at 10:40:18AM -0400, Neal Gompa wrote:
> I don't like saying this, but what it comes down to is that our
> relationship with RHEL has evolved into a one-sided affair. I wish
> someone who is empowered to do something about it would, but the rest
> of us can't.
> 
> Frankly, I suspect you're the only person who could maybe do anything
> about it, and I'm not certain you could do anything about it.

Time to pull back the curtain a little bit, I guess. :)

I think the issue isn't really RHEL-Fedora, but Red Hat-Fedora. Red Hat
isn't a large company in the sense of Oracle or SAP or whatever, let alone
Microsoft or Apple, but it's much bigger than it used to be, and much bigger
than RHEL.

Most of Red Hat's _financial_ engagement in Fedora comes from two places:
Platform (i.e., RHEL) and associated groups like QE, and from the CTO's
office via OSAS. In the first bucket, that's hardware and infrastructure,
the people paid to be on the community infra team (and work in Fedora
Infrastructure and Rel-Eng), and me. In the second, the CTO's office, that's
Bex — and now Sanja on CoreOS and Silverblue — and also our community
budget.

On the Platform side, it's easy (and, increasingly so, really!) to get Red
Hat interested Fedora technology that has a direct connection to improving,
well, the platform. This is the answer to why funding for Pagure and not
HyperKitty or Hubs. The src.fedoraproject.org thing and what we're working
on with shared dist-git with CentOS... easy dots to connect. This part of
Red Hat *cares* about Fedora as a succcessful community, but also has to
justify spending, and as the company overall invests in OpenShift in the
Enterprise, there's not a lot of extra.

Meanwhile, the other side of the coin, over in the CTO's office — Fedora's
community budget and staffing is a significant chunk already. (The Discourse
experiment funding is coming through Sanja and not the Fedora community
budget, FWIW.)

As much as I think the CTO's office *should*, they don't have a group of
programmers available to work on community open source tooling. I definitely
am pushing as much as I can for more of that kind of investment, and ...
maybe some things will bear fruit. I have to say, though (since it's
super-relevant to the discussion here) one of the very first questions I get
every time is: "Why does Fedora have so much of its own stuff when there are
open source alternatives? What's with the huge NIH complex?" I do a lot of
shoving rocks uphill on that one!

But if we want this to be a two-way balanced relationship, it can't be all
"Red Hat isn't spending enough money on Fedora's non-engineering needs!".
What else do you (not just Neal — take this as an open question!) think we
should do differently from a Red Hat side?


-- 
Matthew Miller

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

Re: Fedora should replace mailing lists with Discourse

[Kevin Fenzi]

On 10/19/18 6:43 AM, Neal Gompa wrote:
> On Fri, Oct 19, 2018 at 9:16 AM Gerald B. Cox  wrote:
>>
>> Again, I believe some are trying to do an apples to apples comparison with 
>> Discourse and mailing list technologies.  Discourse was build from the 
>> ground up with the goal of fostering communication and collaboration.  
>> Hyperkitty is a bolt on HTML to mailing list archives.  It's good for what 
>> it is, but it isn't Discourse - and usage numbers tend to bear that out.
>>
> 
> That's an unfair characterization. HyperKitty was designed from the
> ground up with that goal in mind too. The _sole_ difference is the
> backend approach. Discourse uses a database system while HyperKitty
> uses a mail list engine.
> 
> You know why the usage numbers bear that out? Because the upgrade to
> HyperKitty was mishandled and delayed over and over. We were screwed
> over by the fact that our infrastructure doesn't run on Fedora, so
> that made it harder to get it working. The initial deployment was very
> slow and unoptimized. Bugs in the UI remained unfixed in Fedora's
> installation even though upstream fixed them. I would not be surprised
> if upstream ignores us because we don't seem to be upgrading.

Huh, you do realize that things take as long as they take, and there's
no magic wand for 'it's magically done'. mailman3 was a massive
undertaking with a very small group of developers, many of whom were
wanting things to be really done before releasing them.

Much of our infrastructure does run on Fedora, and mailman3 could too if
we needed it to. It just wasn't the decision at the time.
Bugs remain unfixed because there's not too much bugfixing going on.
I see two commits in this month, 2 last month, 1 the month before...

You can always ask why we aren't upgrading. In this case it's because we
are moving stuff to python36 from 34. If these fixes are urgent let us
know and we can re-evaluate and try and get things faster. I was under
the impression that the fixes were pretty minor.

...snip...

> We have not taken good care of our mail list infrastructure. I don't
> blame our infra team. I blame the fact our infra runs on RHEL, and
> RHEL has handicapped us in so many ways because of their own choices.
> Fedora can't control its own (infrastructure) destiny because we have
> no power to influence RHEL at all. And that's broken.

Thats simply not the case. We run many things on Fedora. We do so where
it makes sense and RHEL where that makes sense, and increasingly
OpenShift when that makes sense. ;)

I attempted to use the discourse rss feeds this last week, and they
were... not great. I still need to try mailing list mode before speaking
much more on it.

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1640572] Upgrade perl-Test-PostgreSQL to 1.27

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

Re: Fedora should replace mailing lists with Discourse

[Matthew Miller]

On Fri, Oct 19, 2018 at 12:19:43PM -0400, Neal Gompa wrote:
> I'm more afraid that it'll be a success with casualties. In other
> words, it'll be a failure but not look like one at a glance. Driving
> people away and making it harder to keep track of topics of import is
> going to necessarily constrain how much people are able and willing to
> do. It doesn't get simpler than that. And I have *not* seen a
> Discourse instance be successful in that with large teams, much less
> large groups like the development groups within Fedora.

Yeah -- this is completely reasonable!

-- 
Matthew Miller

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

Re: Fedora should replace mailing lists with Discourse

[Neal Gompa]

On Fri, Oct 19, 2018 at 12:00 PM Gerald B. Cox  wrote:
>
> On Fri, Oct 19, 2018 at 8:31 AM Chris Adams  wrote:
>>
>> Once upon a time, R P Herrold  said:
>> > This seems very tone deaf and lacking in introspection, Matt
>> >
>> > perhaps by reading the subject line you chose to start this
>> > thread with
>>
>> Matt didn't choose that - that subject was set by Gerald B. Cox.
>>
> As I previously mentioned with all the top-posting, excerpts and hyperbole 
> interjected by others people
> get lost and run with mis-quotes - perhaps Discourse could help with that.  
> ;-)
>
> Software is a tool for me.  I don't get emotionally attached to it - as some 
> people apparently are.  It's a bit telling that
> many people seem to be afraid that Discourse will be a success.
>

I'm more afraid that it'll be a success with casualties. In other
words, it'll be a failure but not look like one at a glance. Driving
people away and making it harder to keep track of topics of import is
going to necessarily constrain how much people are able and willing to
do. It doesn't get simpler than that. And I have *not* seen a
Discourse instance be successful in that with large teams, much less
large groups like the development groups within Fedora.


-- 
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 29 compose report: 20181017.n.0 changes

[Lokesh Mandvekar]

On Thu, Oct 18, 2018 at 11:02:27PM +0200, Fabio Valentini wrote:
> On Thu, Oct 18, 2018 at 10:02 PM Lokesh Mandvekar
>  wrote:
> >
> >
> > On Thu, Oct 18, 2018 at 06:50:51PM +0200, Fabio Valentini wrote:
> > >
> > > I'm confused by this podman build. Especially so with my Packaging
> > > Committee hat on.
> > >
> > > - changelog message says it's version 10.1
> > > - %{version} is 0.10.1
> > > - github project has 0.10.1 tag, but its commit hash doesn't match
> > > what's built here
> > > - Release matches the (old!) pattern for a snapshot build
> > > - Epoch is set to 1 if fedora > 28?
> > >
> > > Looking at the .spec file didn't help me, it's a hot mess.
> > >
> > > Can somebody enlighten me about:
> > > Is this a snapshot build? Is it a stable release?
> > > If it's a stable build, why doesn't the commit hash match up with the
> > > appropriate tag?
> >
> > Should be fixed with the latest bump to v0.10.1.3 on rawhide, f29 and f28.
> > Please let me know if something still looks off.
> 
> The commit hash and release tag now match up, so that's better. And
> the usage of Epoch seems to be ... more correct.
> Everything else is either unchanged or worse (for example, the new
> changelog entries don't match the actual version-release of the build
> at all).

Done https://bodhi.fedoraproject.org/updates/FEDORA-2018-8f0690a978 .

FWIW, rawhide will always include the 'dev' string in release tag since it'll
have daily auto rebuilds using upstream master.

Let me know if anything else ..
> 
> > Thanks,
> > --
> > Lokesh
> > IRC, GitHub: lsm5
> > GPG: 0xC7C3A0DD
> > https://keybase.io/lsm5
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

-- 
Lokesh
IRC, GitHub: lsm5
GPG: 0xC7C3A0DD
https://keybase.io/lsm5
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Gerald B. Cox]

On Fri, Oct 19, 2018 at 8:31 AM Chris Adams  wrote:

> Once upon a time, R P Herrold  said:
> > This seems very tone deaf and lacking in introspection, Matt
> >
> > perhaps by reading the subject line you chose to start this
> > thread with
>
> Matt didn't choose that - that subject was set by Gerald B. Cox.
>
> As I previously mentioned with all the top-posting, excerpts and hyperbole
interjected by others people
get lost and run with mis-quotes - perhaps Discourse could help with that.
;-)

Software is a tool for me.  I don't get emotionally attached to it - as
some people apparently are.  It's a bit telling that
many people seem to be afraid that Discourse will be a success.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Chris Adams]

Once upon a time, R P Herrold  said:
> This seems very tone deaf and lacking in introspection, Matt
> 
> perhaps by reading the subject line you chose to start this 
> thread with

Matt didn't choose that - that subject was set by Gerald B. Cox.
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[R P Herrold]

On Fri, 19 Oct 2018, Matthew Miller wrote:

>> Neal Gompa: 
>> because you're dead set on this anyway.

> Matt Miller:
> I ... don't know how to engage constructively with this accusation, because
> it it seems to come from absolutely nowhere. Yes, we're *definitely* trying

This seems very tone deaf and lacking in introspection, Matt

perhaps by reading the subject line you chose to start this 
thread with

No mention of trying out, no mention of a trial.  Just the 
usual 'this is a done deal' announcement on an extremely high 
volume mailing list

I had trialled Discourse six months ago, leaving it on for 
days at a time.  The web client had a leak down in it 
somewhere, My baseline load average went up and I ended up 
with a frozen web browser once all free ram and swap was 
exhausted.  Migrate or not as you wish, it will simply be 
another place where Fedoraproject went off the tracks, chasing 
a mythical low involvement 'tire kicker' instead of supporting 
developers using mature tools and technologies (mailing lists, 
bugzilla, procmail sorting, mutt or alpine)


The non-migratation capabilities of early MM3 efforts have 
been detailed earlier in this thread.  Hyperkitty pretends a 
33 character hash conveys more information than the MM2 model 
for pipermail, or say: MMDD-, but no-one was willing 
to critique a bad choice

Pagure is great and all, but I recall filing a bug ... 
somewhere ... pagure, git, how knows ... about a cross-site 
inter-panel info leak, but there is no SPOT -- single point of 
truth -- in Fedora's hall of mirrors to find it later ad hoc.  
That does not happen with Bugzilla as I have a portfolio of 
several dozen custom searches that would reveal it to me with 
a couple clicks

But charging off to a new shiny hill seems more important to 
Fedoraproject

** shrug **

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

Re: Fedora should replace mailing lists with Discourse

[Nicolas Mailhot]

Le vendredi 19 octobre 2018 à 07:54 -0700, Gerald B. Cox a écrit :
> On Fri, Oct 19, 2018 at 7:43 AM Nicolas Mailhot <
> 
> You really should try it, you might like it.  BTW, there are no ads in
> the Fedora Discourse instance, so
> not sure what you are talking about there.  As far as email is
> concerned the trends are clear... just do a 
> web search.

Ah yes, the advertising industry, that created the web forum bubble and
its social media derivative, publishes report after report they're the
thing and no one is using mail any more, so you can safely invest even
more money advertising on web forums and social media.

In the meanwhile? Websites still use mail. People who do work still use
mail. Anyone who needs to publish anything he wants to be able to find
some years later still uses mail, or simple websites. Even so-called
millenials move to mail, as soon as they need to fill taxes, or anything
else that requires tracking things for years, and they notice the hard
way the transient nature of web forums and social media (transient
*except* for the extracted personal data).

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

[Bug 1639574] Upgrade perl-Data-Types to 0.14

[bugzilla]

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

Robin Lee  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Data-Types-0.14-1.fc30
 Resolution|--- |RAWHIDE
Last Closed||2018-10-19 11:17:19



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

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

[Lennart Poettering]

On Fr, 19.10.18 09:12, Florian Weimer (fwei...@redhat.com) wrote:

> >> (cross-posting to devel and desktop lists, ideally reply to both)
> >
> > Coincidentally, at All Systems Go! in Berlin last week I had some
> > discussions with kernel people about RLIMIT_NOFILE defaults. They
> > basically suggested that the memory and performance cost of large
> > numbers of fds on current kernels is cheap, and that we should bump
> > the hard limit in systemd for all userspace processes.
> 
> Which kernel version is that?  Is that a new patch?  Or some older
> kernel?
> 
> It's definitely not true for kernel 4.18, see the script I posted.

I inquired Tejun Heo about this all, this is what he replied:


In cgroup1, socket buffers are handled by a separate memory
sub-controller. It's cumbersome to use, somewhat broken and doesn't
allow for comprehensive memory control. cgroup2, however, by default
accounts socket buffer as part of a given cgroup's memory consumption
correctly interacting with socket window management.

OOM killer too fails to take socket buffer into account and high
number of sockets can lead it to make ineffective decisions; however,
this failure mode isn't confined to high number of sockets at all -
fewer number of fat pipes, tmpfs, mount points or any other kernel
objects which can be pinned by processes can trigger this.

cgroup2 can track or control most of these usages and at least for us
switching to oomd for workload health management solves most of the
problems that we've encountered. In the longer term, the kernel OOM
killer can be improved to make better decisions too.


("us" in the above is facebook btw.)

So, yeah, if we'd use cgroupv2 on Fedora, then everything would be
great (unfortunately the container messiness blocks that for now). But
as long as we don't, lifting the fd limit is not really making things
worse, given that there are tons of other easily exploitable ways to
acquire untracked memory...

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Building Steam Proton on Fedora

[Kamil Paral]

On Thu, Oct 18, 2018 at 5:39 PM Dridi Boukelmoune <
dridi.boukelmo...@gmail.com> wrote:

> On Thu, Oct 18, 2018 at 5:21 PM Rex Dieter  wrote:
> >
> > Steam is currently available from rpmfusion, fwiw/fyi/ymmv :
> > https://pkgs.rpmfusion.org/cgit/nonfree/steam.git/
>
> It is, and as usual, thanks to the rpmfusion folks! The reason why I
> tried this outside of Fedora first is that steam is part of the
> nonfree repo and as I said in my previous email I can't run non-Steam
> programs via Steam Play, so I need to run Proton directly.
>
> Installing steam from rpmfusion wouldn't help unfortunately.
>

I don't know how to build Proton and the people who reported Proton works
for them on Fedora are simply referring to the bundled Proton in Steam
installation, I believe. However, it should be possible to use
Steam-bundled Proton to run arbitrary Windows executables, not just those
provided by Steam, if you don't mind some tinkering:

https://www.reddit.com/r/SteamPlay/comments/99z9o9/running_games_standalone_via_proton/e4rr7rv/
https://www.reddit.com/r/Steam/comments/99fjzw/steam_proton_for_non_steam_applications/
https://www.reddit.com/r/SteamPlay/comments/9bhvxh/how_do_i_run_a_non_steam_game_with_proton/
https://www.reddit.com/r/SteamPlay/comments/9anque/steamplayprotonlutris_cheat_sheet/
https://github.com/ValveSoftware/Proton/issues/260#issuecomment-427607859
https://forum.level1techs.com/t/windows-games-on-steam-for-linux-proton-client-testing-grounds/131219/71

I haven't personally tried that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Gerald B. Cox]

On Fri, Oct 19, 2018 at 7:43 AM Nicolas Mailhot 
wrote:

> Le vendredi 19 octobre 2018 à 07:28 -0700, Gerald B. Cox a écrit :
> > And if this conversation were in Discourse, we could simply move it to
> > a new topic ;-)
>
> And if it where is discourse I would’t participate in it.
>
> Basically, as others said, not interested in shiny tech that has no
> notion of interop, has a single implementation, and a shelf life of a
> couple years.
>
> There's a reason every single web site out there quietly drops the shiny
> things bit to fall back on email and sms as soon as it manipulates
> anything $$$ related. email and sms are an ugly but reliable and
> standard way to reach anyone. The native web forums are just ephemeral
> eye-cather mutually incompatible things designed make you read ads (as
> Mairin explained better than me).
>
> Now, it it were packaged in Fedora, and deployed on Fedora infra,
> without any magic call to a third party website, that would be something
> else. Wouldn't change the probability upstream would give up on it as
> soon as it was not shiny and cool anymore, but at least I and Fedora
> would not totally depend on them for our data.
>

You really should try it, you might like it.  BTW, there are no ads in the
Fedora Discourse instance, so
not sure what you are talking about there.  As far as email is concerned
the trends are clear... just do a
web search.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Gerald B. Cox]

On Fri, Oct 19, 2018 at 7:41 AM Neal Gompa  wrote:

>
>
> I'm not talking about you in the Fedora sense. I'm talking about
> Gerald and his saying "we must move everything to Discourse".
>

Oh really... I said that... perhaps you should take 5 seconds and read the
subject of the thread.

As far as Hyperkitty is concerned you need to take a few minutes and
re-read Matt's response.

But again, Hyperkitty is not the point of this thread.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Nicolas Mailhot]

Le vendredi 19 octobre 2018 à 07:28 -0700, Gerald B. Cox a écrit :
> And if this conversation were in Discourse, we could simply move it to
> a new topic ;-)

And if it where is discourse I would’t participate in it.

Basically, as others said, not interested in shiny tech that has no
notion of interop, has a single implementation, and a shelf life of a
couple years.

There's a reason every single web site out there quietly drops the shiny
things bit to fall back on email and sms as soon as it manipulates
anything $$$ related. email and sms are an ugly but reliable and
standard way to reach anyone. The native web forums are just ephemeral
eye-cather mutually incompatible things designed make you read ads (as
Mairin explained better than me).

Now, it it were packaged in Fedora, and deployed on Fedora infra,
without any magic call to a third party website, that would be something
else. Wouldn't change the probability upstream would give up on it as
soon as it was not shiny and cool anymore, but at least I and Fedora
would not totally depend on them for our data.

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

Re: Fedora should replace mailing lists with Discourse

[Neal Gompa]

On Fri, Oct 19, 2018 at 10:11 AM Matthew Miller
 wrote:
>
> On Fri, Oct 19, 2018 at 09:43:48AM -0400, Neal Gompa wrote:
> > It's also bad for archiving, since threads are inherently unstable.
> > Conversation splitting and merging is very awkward (as I've observed
> > in the Snapcraft Discourse). I can keep going, but it doesn't matter,
> > because you're dead set on this anyway.
>
> I ... don't know how to engage constructively with this accusation, because
> it it seems to come from absolutely nowhere. Yes, we're *definitely* trying
> out Discourse. That's not a conspiracy — it's live! We're also trying out
> HyperKitty. It's live too! We try stuff!
>

Do not misunderstand me, I don't mind trying out Discourse for certain
types of conversations if we want to, and clearly some communities in
Fedora do.

But I feel like we've done a bad job with giving HyperKitty a fair
shake. The same thing happened with Pagure too, but someone had the
wherewithal to push everything forward enough to make it a success,
and even now I'll say that Pagure is a nice environment. Yeah, Pagure
is still missing things I wish it had, but it's evolving and growing.
It took a few years, but it happened.

I know that the big promotion push for HyperKitty was supposed to come
with Hubs, but somehow that project died before it could go anywhere,
so...

I'm happy to help with infra related stuff, but I'm just not equipped
to do so. Only a few people are. :(

> The rest of everything —  development resources, infrastructure, whether
> there is widespread adoption — that's not something arguing over will
> change. When we can *see* something is not working, we can't just complain
> that those are unfair. we should try something else.
>

The reason I'm arguing about it now is because it doesn't seem to be
fixable from the background. We just keep hacking around it over and
over.

I don't like saying this, but what it comes down to is that our
relationship with RHEL has evolved into a one-sided affair. I wish
someone who is empowered to do something about it would, but the rest
of us can't.

Frankly, I suspect you're the only person who could maybe do anything
about it, and I'm not certain you could do anything about it.

> But the comments from several people implying some sort of fait accompli
> here, that some backroom decision has been made, that we're somehow trying
> to destroy communication seriously?
>

I'm not talking about you in the Fedora sense. I'm talking about
Gerald and his saying "we must move everything to Discourse".


-- 
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Anderson, Charles R]

On Fri, Oct 19, 2018 at 10:10:22AM -0400, Matthew Miller wrote:
> I ... don't know how to engage constructively with this accusation, because
> it it seems to come from absolutely nowhere. Yes, we're *definitely* trying
> out Discourse. That's not a conspiracy — it's live! We're also trying out
> HyperKitty. It's live too! We try stuff!

Can you please turn on the ability to create new threads via
email/mailing list mode in Discourse?

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

[Test-Announce] 2018-10-22 @ 16:00 UTC - Fedora 29 Blocker Review Meeting

[Geoffrey Marr]

# F29 Blocker Review meeting
# Date: 2018-10-22
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net

Hey everyone,

We currently (as of 2018-10-18 at 22:00UTC) have 10 accepted blockers, 5
proposed freeze exceptions, and 11 accepted freeze exceptions. Let's take
Monday to review the accepted and vote on whatever is left before we
(hopefully) get a compose going on Monday or Tuesday.

*It will be extremely helpful to get votes IN-BUG for this, as if we wait
until the meeting to take care of all the blockers, we can almost bet on
not having a compose in time for Go/No-Go next Thursday. Please vote in-bug
before the meeting!*



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

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

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

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

Have a good weekend and see you on Monday!

[0] https://fedoraproject.org/wiki/Fedora_Release_Criteria

Geoff Marr
IRC: coremodule
___
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://getfedora.org/code-of-conduct.html
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Gerald B. Cox]

And if this conversation were in Discourse, we could simply move it to a
new topic ;-)

On Fri, Oct 19, 2018 at 7:21 AM Nicolas Mailhot 
wrote:

> Le vendredi 19 octobre 2018 à 14:55 +0100, Daniel P. Berrangé a écrit :
> >
> > I don't know why Red Hat's mailman impl isn't upgraded, but it is
> > not blocked by lack of Python 3 on RHEL.
> >
> > Red Hat Software Collections have been providing Python 3.x versions
> > that run on RHEL since ~2013. They exist as add-on yum repos,
>
> Well that's another thing 200% broken in the current Fedora RHEL
> universe (and I speak both with my Fedora contributor hat, and as
> someone who was tasked with procuring RHEL systems in a fortune xxx
> company not so long ago).
>
> The whole "but it's in an optional RHEL repo" just kills *any* form
> RHEL/Fedora symbiosis.
>
> No one but RH knows what ends up in what optional repo for what reason,
> they're ignored by Centos, it's completely impossible to push anything a
> tad complex from Fedora to EPEL because it will depend on things RH
> stashed away in an optional repo centos does not rebuild, and you're
> forbidden to put a copy in EPEL because it may collide with the optional
> repos, and so on.
>
> That's how we end up with the hilarious situation where the Go EPEL6
> stack is both newer and more complete than the Go EPEL7 stack because RH
> vacuumed some Go packages in an optional EL7 repo and now it's
> impossible to do anything Go-related in EPEL7.
>
> I'm sure the RH marketoïds *love* the optional repos, it's segmentation
> market 101, but concretely? They're the kiss of death for anything in
> Fedora that has enterprise applications, because almost no one is going
> to bother contributing things in Fedora, that he needs enterprise-side,
> if the result has zero chance of ending up in EPEL.
>
> The end result is that no one but RH contributes to EL optional repos,
> and no one who is working on RH EL7 repos has the slightest interest in
> integrating with Fedora since they do not see any stream of EPEL Fedora
> contributions.
>
> Or, you end up deploying enterprise systems with your own private
> rebuild of Fedora packages for EL, and you know what? At this point the
> bean counters just ask “why are we paying $$$ to RH again, I see you
> spend your time rebuilding Fedora packages, can't you use Debian if the
> EL part of RHEL is useless?”
>
> Regards,
>
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Nicolas Mailhot]

Le vendredi 19 octobre 2018 à 14:55 +0100, Daniel P. Berrangé a écrit :
> 
> I don't know why Red Hat's mailman impl isn't upgraded, but it is
> not blocked by lack of Python 3 on RHEL.
> 
> Red Hat Software Collections have been providing Python 3.x versions
> that run on RHEL since ~2013. They exist as add-on yum repos, 

Well that's another thing 200% broken in the current Fedora RHEL
universe (and I speak both with my Fedora contributor hat, and as
someone who was tasked with procuring RHEL systems in a fortune xxx
company not so long ago).

The whole "but it's in an optional RHEL repo" just kills *any* form
RHEL/Fedora symbiosis.

No one but RH knows what ends up in what optional repo for what reason,
they're ignored by Centos, it's completely impossible to push anything a
tad complex from Fedora to EPEL because it will depend on things RH
stashed away in an optional repo centos does not rebuild, and you're
forbidden to put a copy in EPEL because it may collide with the optional
repos, and so on.

That's how we end up with the hilarious situation where the Go EPEL6
stack is both newer and more complete than the Go EPEL7 stack because RH
vacuumed some Go packages in an optional EL7 repo and now it's
impossible to do anything Go-related in EPEL7.

I'm sure the RH marketoïds *love* the optional repos, it's segmentation
market 101, but concretely? They're the kiss of death for anything in
Fedora that has enterprise applications, because almost no one is going
to bother contributing things in Fedora, that he needs enterprise-side,
if the result has zero chance of ending up in EPEL.

The end result is that no one but RH contributes to EL optional repos,
and no one who is working on RH EL7 repos has the slightest interest in
integrating with Fedora since they do not see any stream of EPEL Fedora
contributions.

Or, you end up deploying enterprise systems with your own private
rebuild of Fedora packages for EL, and you know what? At this point the
bean counters just ask “why are we paying $$$ to RH again, I see you
spend your time rebuilding Fedora packages, can't you use Debian if the
EL part of RHEL is useless?”

Regards,

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

Re: Fedora should replace mailing lists with Discourse

[Matthew Miller]

On Fri, Oct 19, 2018 at 09:43:48AM -0400, Neal Gompa wrote:
> It's also bad for archiving, since threads are inherently unstable.
> Conversation splitting and merging is very awkward (as I've observed
> in the Snapcraft Discourse). I can keep going, but it doesn't matter,
> because you're dead set on this anyway.

I ... don't know how to engage constructively with this accusation, because
it it seems to come from absolutely nowhere. Yes, we're *definitely* trying
out Discourse. That's not a conspiracy — it's live! We're also trying out
HyperKitty. It's live too! We try stuff!

The rest of everything —  development resources, infrastructure, whether
there is widespread adoption — that's not something arguing over will
change. When we can *see* something is not working, we can't just complain
that those are unfair. we should try something else.

But the comments from several people implying some sort of fait accompli
here, that some backroom decision has been made, that we're somehow trying
to destroy communication seriously?

-- 
Matthew Miller

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

Re: Fedora should replace mailing lists with Discourse

[Gerald B. Cox]

On Fri, Oct 19, 2018 at 6:45 AM Neal Gompa  wrote:

> On Fri, Oct 19, 2018 at 9:16 AM Gerald B. Cox  wrote:
> >
> > Again, I believe some are trying to do an apples to apples comparison
> with Discourse and mailing list technologies.  Discourse was build from the
> ground up with the goal of fostering communication and collaboration.
> Hyperkitty is a bolt on HTML to mailing list archives.  It's good for what
> it is, but it isn't Discourse - and usage numbers tend to bear that out.
> >
>
> That's an unfair characterization. HyperKitty was designed from the
> ground up with that goal in mind too. The _sole_ difference is the
> backend approach. Discourse uses a database system while HyperKitty
> uses a mail list engine.
>
> if you think the "sole" difference between HyperKitty and Discourse is the
backend approach
you're not looking very hard.  It's quite apparent just by looking at it.
If yperKitty's design goals
are the exact same as Discourse they hid it pretty well in their online
documentation.


> You know why the usage numbers bear that out? Because the upgrade to
> HyperKitty was mishandled and delayed over and over. We were screwed
> over by the fact that our infrastructure doesn't run on Fedora, so
> that made it harder to get it working. The initial deployment was very
> slow and unoptimized. Bugs in the UI remained unfixed in Fedora's
> installation even though upstream fixed them. I would not be surprised
> if upstream ignores us because we don't seem to be upgrading.
>

I don't agree with that being the reason - I believe it is the design
approach and goals - but
even if that were true - that ship has sailed.


>
> The development process for HyperKitty basically stalled out because
> migrations were impossible from Mailman 2 to Mailman 3 for a *very*
> long time. Fedora somehow did it, and that seemed to have not gone
> back upstream, so until *very recently*, upstream did not recommend
> doing mm2 to mm3 upgrades.
>

This thread isn't about making excuses for Hyperkitty - it's about
Discourse.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Daniel P . Berrangé]

On Fri, Oct 19, 2018 at 09:43:48AM -0400, Neal Gompa wrote:
> That *completely* handicapped adoption of HyperKitty, because
> HyperKitty requires Mailman 3. What's worse, because it's almost
> impossible to run on RHEL due to the lack of Python 3 (which continues
> to anger and frustrate me), Red Hat never migrated their mailing
> lists. Red Hat's lists are one of the larger installations, and it was
> a real blow to not have that migrate.

I don't know why Red Hat's mailman impl isn't upgraded, but it is
not blocked by lack of Python 3 on RHEL.

Red Hat Software Collections have been providing Python 3.x versions
that run on RHEL since ~2013. They exist as add-on yum repos, rather
than part of the base since they have a different support lifecycle
and to avoid interfering with the system python binary which is
depended on by many other apps/tools

  https://access.redhat.com/solutions/472793
  https://access.redhat.com/support/policy/updates/rhscl

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Neal Gompa]

On Fri, Oct 19, 2018 at 9:16 AM Gerald B. Cox  wrote:
>
> Again, I believe some are trying to do an apples to apples comparison with 
> Discourse and mailing list technologies.  Discourse was build from the ground 
> up with the goal of fostering communication and collaboration.  Hyperkitty is 
> a bolt on HTML to mailing list archives.  It's good for what it is, but it 
> isn't Discourse - and usage numbers tend to bear that out.
>

That's an unfair characterization. HyperKitty was designed from the
ground up with that goal in mind too. The _sole_ difference is the
backend approach. Discourse uses a database system while HyperKitty
uses a mail list engine.

You know why the usage numbers bear that out? Because the upgrade to
HyperKitty was mishandled and delayed over and over. We were screwed
over by the fact that our infrastructure doesn't run on Fedora, so
that made it harder to get it working. The initial deployment was very
slow and unoptimized. Bugs in the UI remained unfixed in Fedora's
installation even though upstream fixed them. I would not be surprised
if upstream ignores us because we don't seem to be upgrading.

The development process for HyperKitty basically stalled out because
migrations were impossible from Mailman 2 to Mailman 3 for a *very*
long time. Fedora somehow did it, and that seemed to have not gone
back upstream, so until *very recently*, upstream did not recommend
doing mm2 to mm3 upgrades.

That *completely* handicapped adoption of HyperKitty, because
HyperKitty requires Mailman 3. What's worse, because it's almost
impossible to run on RHEL due to the lack of Python 3 (which continues
to anger and frustrate me), Red Hat never migrated their mailing
lists. Red Hat's lists are one of the larger installations, and it was
a real blow to not have that migrate.

The irony that I can probably get SUSE to deploy Mailman 3 and
HyperKitty before Red Hat will is not lost on me.

> The fact is that email usage is declining.  People are moving away from it 
> and prefer to use other platforms for collaboration.  As with many things... 
> when something new comes out, there are a group of people who push back and 
> want things to stay as they are - history has proven time and time again, 
> that change is inevitable.  If something new is the better solution, as 
> people become aware of it and use it - it will become the go to solution.  
> The examples are endless and span multiple disciplines.
>

You know what? I bounce back and forth between HyperKitty and my email
client. If all the lists I subscribed to used HyperKitty, I wouldn't
be using my email client at all. While I don't generally reply from
HK, it's mainly because of bugs that I know are fixed in newer
versions.

We have not taken good care of our mail list infrastructure. I don't
blame our infra team. I blame the fact our infra runs on RHEL, and
RHEL has handicapped us in so many ways because of their own choices.
Fedora can't control its own (infrastructure) destiny because we have
no power to influence RHEL at all. And that's broken.

> Fedora has a long history of supporting new and innovative solutions and 
> toolsets.  That is what helps differentiate us as a distribution.  We need a 
> tool that will encourage more participation.  I believe Discourse will help 
> with this - people will discover new and more efficient ways to do their work 
> and the sun will rise the next day.
>

And yet, for 15 years, Fedora didn't have a web forum for user
support. People have asked for it over the years, and Fedora refused.
That's why things like FedoraForum.org exist instead of being part of
Fedora itself.

I'm a guy who started with web forums who later used email lists, not
the other way around. I vastly prefer forum-style environments. I
still don't like Discourse for this kind of stuff, because it's just
not designed for handling contextual conversations.

And there are problems with Discourse too: doing partial quoting with
attribution is annoying and requires editing the quote to restore that
information. In addition, searching for posts and topics becomes
exponentially slower as the system handles more content, which is a
huge problem if you're trying to find information to cross reference.

It's also bad for archiving, since threads are inherently unstable.
Conversation splitting and merging is very awkward (as I've observed
in the Snapcraft Discourse). I can keep going, but it doesn't matter,
because you're dead set on this anyway.


-- 
真実はいつも一つ！/ 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Attention Gmail users, please turn off HTML mail

[Gerald B. Cox]

On Fri, Oct 19, 2018 at 4:26 AM Matthew Miller 
wrote:

> On Fri, Oct 19, 2018 at 03:53:06AM -, Máirín Duffy wrote:
> > But we can file bugs against Discourse and they will be magically and
> > quickly fixed to our satisfaction, yes?
>
> Of course not. However: development is very active.
> https://github.com/discourse/discourse/commits/master
>
>
> > I'm concerned that those proposing Discourse seem to not have used
> > Hyperkitty at length.
>
> As you know, I was very excited about HyperKitty. I *did* try it very
> seriously at first, but not at length, because it quickly became apparent
> that it wasn't really up to the task of being my primary interface to
> email.
> I just couldn't use it for day-to-day communication. Not necessarily any
> single thing, but lots and lots of fundamentals. How do I get a list of new
> threads? How do I get a list of threads I've read but which have new
> responses, and ideally show only the new responses? How can I mute a thread
> I don't want to be alerted on? How do I get to the next thread from the
> *bottom* of a thread I just read? How can I search... usefully at all? My
> point isn't to rag on HyperKitty, but I could definitely go on.
>
> I tried for a while to file suggestions and bug reports, but especially
> after the extra two years it took to even get deployed, it was *very* clear
> there were no resources for ongoing development from Red Hat, no
> significant
> non-RH Fedora development, and no meaningful outside development either.
> Basic things like https://gitlab.com/mailman/hyperkitty/issues/64 didn't
> even get *responses*. So, I stuck with my previous email client setup.
>
> And the thing is, it's *not just me*. Take a look at
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
> right now. Every single thread shows a "meh" face and "+0/-0". It says
>
>Most popular discussions
>No vote has been cast this month (yet).
>
> It is the 19th of the month. Not a single vote on our most busy mailing
> list. The same is true for every other list I looked at. People just aren't
> using this.
>
> I *really* think HyperKitty has potential. But we can't run on potential.
> Discourse is a pure open source project that is *really catching on and
> successful*. It's not perfect either, of course, but we're way better off
> aligning with something with momentum.
>
>
Completely agree - well stated.  It's quite obvious when using both tools
which lends itself
to better conversation and collaboration.  I realize people are resistant
to change - but once
they start to use and learn about the new features and functionality - most
people come around.
Sometimes people need a nudge to change and adapt - myself included.  It's
just human nature -
but as I get older, I try to keep an open mind and be adaptable.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Gerald B. Cox]

Again, I believe some are trying to do an apples to apples comparison with
Discourse and mailing list technologies.  Discourse was build from the
ground up with the goal of fostering communication and collaboration.
Hyperkitty is a bolt on HTML to mailing list archives.  It's good for what
it is, but it isn't Discourse - and usage numbers tend to bear that out.

The fact is that email usage is declining.  People are moving away from it
and prefer to use other platforms for collaboration.  As with many
things... when something new comes out, there are a group of people who
push back and want things to stay as they are - history has proven time and
time again, that change is inevitable.  If something new is the better
solution, as people become aware of it and use it - it will become the go
to solution.  The examples are endless and span multiple disciplines.

Fedora has a long history of supporting new and innovative solutions and
toolsets.  That is what helps differentiate us as a distribution.  We need
a tool that will encourage more participation.  I believe Discourse will
help with this - people will discover new and more efficient ways to do
their work and the sun will rise the next day.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Attention Gmail users, please turn off HTML mail

[Pierre-Yves Chibon]

On Fri, Oct 19, 2018 at 03:53:06AM -, Máirín Duffy wrote:
> > On Thu, Oct 04, 2018 at 11:27:02PM -, Ray Strode wrote:
> > 
> > Unfortunately, all is not rosy there. See this thread on the users' list
> > from this fall about confusion with hyperkitty quoting:
> > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.o...
> 
> It's hilarious reading this thread in Hyperkitty and having absolutely no 
> issue understanding which quote is from whom.

You're replying to an email from Matthew but it show here as coming from Ray
Strode. This is the bug Matthew was referring to.

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

Re: Fwd: Re: Vagrant: can we make it show up in Software?

[Brian (bex) Exelbierd]

On Fri, Oct 19, 2018 at 12:39 PM Matthew Miller 
wrote:

>
>
> On Fri, Oct 19, 2018 at 12:34:49PM +0200, Vít Ondruch wrote:
> > So apparently, some CLI apps should probably go into Software, but how
> > are we going to decide that Vagrant and Powertop are fine while Python
> > and GCC are not?
> >
> > Should we keep it upon individual maintainer discretion? Should we
> > somehow evaluate all the cases one by one?
>
> What about a "Command Line tools for Developers" section in Software?


What about non-developer tools? I’m thinking of things like ledger that I
has to help a new budget person install as they’ve only ever used Software.

Regards,

bex



>
>
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
-- 
Brian (bex) Exelbierd | bexel...@redhat.com | b...@pobox.com
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1640993] New: Upgrade perl-WWW-Mechanize to 1.89

[bugzilla]

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

Bug ID: 1640993
   Summary: Upgrade perl-WWW-Mechanize to 1.89
   Product: Fedora
   Version: rawhide
 Component: perl-WWW-Mechanize
  Assignee: emman...@seyman.fr
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, jose.p.oliveira@gmail.com,
ktdre...@ktdreyer.com,
perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk



Latest Fedora delivers 1.88 version. Upstream released 1.89. When you have free
time, please upgrade it

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

[Bug 1640990] New: Upgrade perl-DateTime-TimeZone to 2.20

[bugzilla]

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

Bug ID: 1640990
   Summary: Upgrade perl-DateTime-TimeZone to 2.20
   Product: Fedora
   Version: rawhide
 Component: perl-DateTime-TimeZone
  Assignee: jples...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest Fedora delivers 2.19 version. Upstream released 2.20. When you have free
time, please upgrade it

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

[Bug 1640988] New: perl-Catalyst-Runtime-5.90120 is available

[bugzilla]

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

Bug ID: 1640988
   Summary: perl-Catalyst-Runtime-5.90120 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Catalyst-Runtime
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, iarn...@gmail.com,
perl-devel@lists.fedoraproject.org,
trem...@tremble.org.uk



Latest upstream release: 5.90120
Current version/release in rawhide: 5.90119-1.fc30
URL: http://search.cpan.org/dist/Catalyst-Runtime/

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

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

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

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

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

[Bug 1640987] New: Upgrade perl-Business-ISMN to 1.201

[bugzilla]

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

Bug ID: 1640987
   Summary: Upgrade perl-Business-ISMN to 1.201
   Product: Fedora
   Version: rawhide
 Component: perl-Business-ISMN
  Assignee: c...@m.fsf.org
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: c...@m.fsf.org, mefos...@gmail.com,
perl-devel@lists.fedoraproject.org



Latest Fedora delivers 1.132 version. Upstream released 1.201. When you have
free time, please upgrade it

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

Re: Fedora should replace mailing lists with Discourse

[Federico Bruni]

> On 2018-10-17 13:41, John Florian wrote:
> 
> How does Discourse handle posts you've already read in a 
> thread that's still active.  With things like reddit or LWN, you get to 
> read it over and over and over again if you really want to see whats new 
> now.

It handles it very well.
You don't have to read it over and over; just click on the thread and you'll 
jump to the first unread message.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Federico Bruni]

> On Thursday, 18 October 2018 at 23:04, Dominik wrote:
> [...]
> 
> So, I tried to answer in one of the threads and it's quite difficult,
> in my opinion. The message compose pop-up doesn't quote the message
> I'm replying to, so I can't write my comments in response to specific
> passages by the previous person. Not being able to reply in context
> is a deal-breaker to me. What do you call "a richer experience",
> I wonder.
> 

In Discourse you have two options:

1. Quote the whole post: first hit reply, then click on the bubble icon to 
quote the whole post you are replying to.

2. Quote part of the message: select the text you want to quote with the mouse 
and a Quote button will pop up; click on it and you are ready to reply.

See this cheat sheet: 
https://www.sitepoint.com/community/t/discourse-cheat-sheet/733

BTW, Hyperkitty doesn't have the partial quoting feature AFAICT.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Attention Gmail users, please turn off HTML mail

[Matthew Miller]

On Fri, Oct 19, 2018 at 03:53:06AM -, Máirín Duffy wrote:
> But we can file bugs against Discourse and they will be magically and
> quickly fixed to our satisfaction, yes?

Of course not. However: development is very active. 
https://github.com/discourse/discourse/commits/master


> I'm concerned that those proposing Discourse seem to not have used
> Hyperkitty at length.

As you know, I was very excited about HyperKitty. I *did* try it very
seriously at first, but not at length, because it quickly became apparent
that it wasn't really up to the task of being my primary interface to email.
I just couldn't use it for day-to-day communication. Not necessarily any
single thing, but lots and lots of fundamentals. How do I get a list of new
threads? How do I get a list of threads I've read but which have new
responses, and ideally show only the new responses? How can I mute a thread
I don't want to be alerted on? How do I get to the next thread from the
*bottom* of a thread I just read? How can I search... usefully at all? My
point isn't to rag on HyperKitty, but I could definitely go on.

I tried for a while to file suggestions and bug reports, but especially
after the extra two years it took to even get deployed, it was *very* clear
there were no resources for ongoing development from Red Hat, no significant
non-RH Fedora development, and no meaningful outside development either.
Basic things like https://gitlab.com/mailman/hyperkitty/issues/64 didn't
even get *responses*. So, I stuck with my previous email client setup.

And the thing is, it's *not just me*. Take a look at 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
right now. Every single thread shows a "meh" face and "+0/-0". It says

   Most popular discussions
   No vote has been cast this month (yet).

It is the 19th of the month. Not a single vote on our most busy mailing
list. The same is true for every other list I looked at. People just aren't
using this.

I *really* think HyperKitty has potential. But we can't run on potential.
Discourse is a pure open source project that is *really catching on and
successful*. It's not perfect either, of course, but we're way better off
aligning with something with momentum.


-- 
Matthew Miller

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

Self Introduction: Kefu Chai

[Kefu Chai]

Hey, my name is Kefu Chai, and my nick name on IRC is kefu.

I am a software developer using C++ and Python. I found that fmt[0] is a very 
good C++ library for C++ developers like me who whats to have python's 
str.format() in C++. But its package[1] was recently orphaned. I've been using 
fedora for couple years in my work. I think it's an opportunity for me to 
contribute to this project by being a maintainer of this package.

The review request for fmt can be found at 
https://bugzilla.redhat.com/show_bug.cgi?id=1638768 .

Cheers

--
[0] https://github.com/fmtlib/fmt
[1] https://apps.fedoraproject.org/packages/fmt
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: PSA: builds using forge macros with tags broken on rawhide

[Nicolas Mailhot]

Le vendredi 19 octobre 2018 à 11:48 +0200, Nicolas Mailhot a écrit :
> Le vendredi 19 octobre 2018 à 04:58 -0400, Jakub Cajka a écrit :
> > And what about backing up the breaking change in Rawhide? At least
> > until there is a backward compatible way of doing that(or it is
> > backported in to the stable releases)?
> 
> We're talking about redhat-rpm-config there. No one wants to backport
> redhat-rpm-config changes to stable directly, without some proof
> period
> in devel first (and that decision is pretty much in FPC’s hands
> anyway).
> 
> The “fastest” path I see is several people telling FPC the change is
> ok
> now and the backport should not be delayed any more. And maybe we are
> all being overly cautious and the caution delay does more harm than
> good
> 
> I will prepare a backport PR.

Anyway are the backport PRs

https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/44
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/43
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/42

Regards,

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

Re: Fwd: Re: Vagrant: can we make it show up in Software?

[Richard Hughes]

On Fri, 19 Oct 2018 at 11:38, Matthew Miller  wrote:
> What about a "Command Line tools for Developers" section in Software?

We've got a developers top level, so I think a CLI tools subsection
would be fine.

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

Re: Fwd: Re: Vagrant: can we make it show up in Software?

[Matthew Miller]

On Fri, Oct 19, 2018 at 12:34:49PM +0200, Vít Ondruch wrote:
> So apparently, some CLI apps should probably go into Software, but how
> are we going to decide that Vagrant and Powertop are fine while Python
> and GCC are not?
> 
> Should we keep it upon individual maintainer discretion? Should we
> somehow evaluate all the cases one by one?

What about a "Command Line tools for Developers" section in Software?



-- 
Matthew Miller

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

Re: Fwd: Re: Vagrant: can we make it show up in Software?

[Vít Ondruch]

So apparently, some CLI apps should probably go into Software, but how
are we going to decide that Vagrant and Powertop are fine while Python
and GCC are not?

Should we keep it upon individual maintainer discretion? Should we
somehow evaluate all the cases one by one?


V.


Dne 19. 10. 18 v 12:24 Richard Hughes napsal(a):
> On Fri, 19 Oct 2018 at 09:36, Vít Ondruch  wrote:
>> I was always under impression, that we don't want to show CLI apps in
>> Software. Not sure what was the reasoning behind, but I can imagine that:
>> * we don't want Python to show up in Software (for example)
> Right, agreed.
>
>> * screenshots of terminal window are not really attractive
> Also agreed.
>
>> Reading the AppData guidelines [1], it states several times something
>> like "If a package contains a GUI application" never mentions CLI. That
>> just strengthens my impression. So should we extend the guidelines to
>> support CLI apps?
> I think you have to be careful. I don't think we want every CLI
> application, and I don't think we want to have frameworky things like
> GCC available in software either, but somethings do make sense. For
> instance, powertop seems a useful thing to have, especially if you can
> launch it straight from gnome-software. I don't think a simple "no
> command line apps" stance is so useful now.
>
> Richard.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fwd: Re: Vagrant: can we make it show up in Software?

[Richard Hughes]

On Fri, 19 Oct 2018 at 09:36, Vít Ondruch  wrote:
> I was always under impression, that we don't want to show CLI apps in
> Software. Not sure what was the reasoning behind, but I can imagine that:
> * we don't want Python to show up in Software (for example)

Right, agreed.

> * screenshots of terminal window are not really attractive

Also agreed.

> Reading the AppData guidelines [1], it states several times something
> like "If a package contains a GUI application" never mentions CLI. That
> just strengthens my impression. So should we extend the guidelines to
> support CLI apps?

I think you have to be careful. I don't think we want every CLI
application, and I don't think we want to have frameworky things like
GCC available in software either, but somethings do make sense. For
instance, powertop seems a useful thing to have, especially if you can
launch it straight from gnome-software. I don't think a simple "no
command line apps" stance is so useful now.

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

Re: PSA: builds using forge macros with tags broken on rawhide

[Nicolas Mailhot]

Le vendredi 19 octobre 2018 à 04:58 -0400, Jakub Cajka a écrit :
> 
> And what about backing up the breaking change in Rawhide? At least
> until there is a backward compatible way of doing that(or it is
> backported in to the stable releases)?

We're talking about redhat-rpm-config there. No one wants to backport
redhat-rpm-config changes to stable directly, without some proof period
in devel first (and that decision is pretty much in FPC’s hands anyway).

The “fastest” path I see is several people telling FPC the change is ok
now and the backport should not be delayed any more. And maybe we are
all being overly cautious and the caution delay does more harm than good
.

I will prepare a backport PR.

Whether it's applied or not (and when) is something else. The change
that hit devel recently was queued in the review pipe two months ago.

And there's also PR35, that will add further changes, and has been
cooking quite a lot of time already. Though it will be mostly new
features, now that the forge URL fixes have hit devel.

Regards,

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

Re: Fedora should replace mailing lists with Discourse

[Philip Rhoades]

Máirín,


On 2018-10-19 14:43, Máirín Duffy wrote:

I'm open to all of those suggestions as well as committing to design
and CSS work for them. I would need a web dev to help me though; I'm
not great with Django.

Please note, the reason Hyperkitty didn't cause this sort of thread or
honestly any sort of drama or controversy when it was deployed is
because it required no current users to change anything about their
workflow, with one small exception - mm3 didn't come out w topic
support which was used on the packagers list. (I don't believe that's
an issue anymore.)

The whole point of the design was to enable a new group of would be
contributors be able to participate alongside the folks already there,
so that everyone could participate together. Existing ML users never
need to use Hyperkitty if they don't want to, and yet, users new to
the project can start reading and participating in threads right away
w no mail client config and never receiving a single email if they so
desire.

I believe quite strongly (and have from the start when I first heard
of the project) that Discourse's basic UX model is fundamentally
flawed. If we deploy discourse and roll it out, we *may* get new
users, but as noted in this thread, we will lose existing ones.
Participating in upstream effort on Discourse, improving it, etc is
foolish bc the fundamental model is broken.

When some people think of email, they think of mutt or thunderbird,
annoying client config, setting up procmail or fetchmail or whatever
other complex elaborate tools many of the ppl reading this use. Email
is just a basic standard. Discourse does not follow that standard.
There is no reason a social media timeline like experience for the
teenagers is not possible using email as the underlying system. Jabber
never really took off, except Google Hangouts and FB messenger both
used it (no idea if they still do.) The reason our open standards like
email and xmpp are dying off is bc the primary biz model of the
companies that used them relies on getting eyes on ads, and scanning
content in ways that mean giving users a choice of client that works
best for their needs is off the table.

Basically dont confuse the front end youre used to with the underlying 
tech.


I think it's a better idea to use a tool based on open standards, that
allows users to use the client experience that works best for them. If
you try to force everyone down one road it won't work.



A nice, informed response!

Thanks,

Phil.
--
Philip Rhoades

PO Box 896
Cowra  NSW  2794
Australia
E-mail:  p...@pricom.com.au
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1640572] Upgrade perl-Test-PostgreSQL to 1.27

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Test-PostgreSQL-1.27-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-c06406ea2f

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

[Bug 1640572] Upgrade perl-Test-PostgreSQL to 1.27

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Test-PostgreSQL-1.27-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-5908a39c91

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

Re: PSA: builds using forge macros with tags broken on rawhide

[Jakub Cajka]

- Original Message -
> From: "Nicolas Mailhot" 
> To: "Development discussions related to Fedora" 
> 
> Cc: "Fabio Valentini" 
> Sent: Monday, October 15, 2018 11:56:45 AM
> Subject: Re: PSA: builds using forge macros with tags broken on rawhide
> 
> Le 2018-10-15 09:09, Fabio Valentini a écrit :
> 
> > Because right now, package builds prepared on fedora 27-29 will result
> > in failing koji builds for rawhide - and nobody should have to install
> > rawhide to be able to build packages.
> 
> Well basically you can
> 1. use a rawhide vm on container of whatever to prepare your rawhide
> srpms (but, as you noted, not cheap to setup)
> 2. use mock --shell to get a cheap rawhide buildroot srpm env (in theory
> that works – not tested)
> 3. use a local rebuild of the rawhide redhat-rpm-config to match rawhide
> behaviour (only takes changing dist definition in
> /etc/macros.d/macros.dist to %{?distprefix}.fcxx
> 4. use a local backport of the code. You basicaly just need to insert
> the following at line 251 or 252 of the macros.forge rawhide file
>-- Workaround releases where distprefix is not used by default
>local dist = rpm.expand("%{?dist}")
>local edistprefix = rpm.expand(distprefix)
>if (edistprefix ~= "") and (string.sub(dist, 1, #edistprefix) ~=
> edistprefix) then
>  rpmmacros.explicitset("dist", "%{?distprefix}" .. dist,verbose)
>end
> 5. ask to accelerate the backport to stable. I can prepare the backport
> PR, but applying the PR is out of my hands
> 6. ask redhat-rpm-config maintainers to process
> https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/35
> since I have a backport already prepared and tested for this one
> 7. all of the above

And what about backing up the breaking change in Rawhide? At least until there 
is a backward compatible way of doing that(or it is backported in to the stable 
releases)?

To be honest we should not introduce deliberately backwards incompatible 
changes without at least publicly announcing them way ahead(and in general 
avoid them). This creates really bad experience for all and waste lot of time 
of the packagers.

JC

> 
> I don’t know which solution best matches your workflow
> 
> And normally, you do stuff in and for rawhide first, and then backport,
> but this is kind of a special case since the rawhide bit does not
> usually extend to the srpm part, and Go packaging in Fedora is so
> immature every release is pretty much a devel release from Go's POW, so
> I understand where you're coming from.
> 
> 
> Regards,
> 
> --
> Nicolas Mailhot
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1640572] Upgrade perl-Test-PostgreSQL to 1.27

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-Test-PostgreSQL-1.27-1.fc29 has been submitted as an update to Fedora 29.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-9709d3a8fa

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

Re: Empty debugsources.list file in build when enabling py2 builds

[Ankur Sinha]

On Fri, Oct 19, 2018 10:16:48 +0200, Nicolas Mailhot wrote:
> 
> > On 19.10.2018 00:28, Ankur Sinha wrote:
> > > 
> > > I'm still at a loss to why this is so. Would someone be able to shed
> > > some light on this please?
> 
> That’s
> https://github.com/rpm-software-management/rpm/issues/551
> 
> for bad old historical reasons the main directory rpmbuild works in is a
> side-effect of %setup (which %autoseup calls behin the scenes), there’s
> no way to override or even read in it %prep, and *many* bits of rpm
> automation will look for stuff in this directory only.

That's quite an informative ticket. Thanks for the link!

The method Miro suggested works well enough, so I'll just use that
convention for the time being.

-- 
Thanks both,
Regards,

Ankur Sinha "FranciscoD"

https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Empty debugsources.list file in build when enabling py2 builds

[Ankur Sinha]

On Fri, Oct 19, 2018 00:52:51 +0200, Miro Hrončok wrote:
>
> 
> The debugsourcefiles.list is constructed from files in the current folder
> the build is in. In your case, that's the %{name}-%{commit} folder from
> %autosetup.
> 
> Anything you create outside that folder is not included.

Ah, right---I suspected it was something of this sort but wasn't able to
find any docs to confirm.

> You do this:
> 
>   cd ../
>   ...
>   cp -a %{name}-%{commit} %{name}-%{commit}-py2
> 
> 
> And ../%{name}-%{commit}-py2 is not included.
> 
> If you really need to do this, create those as subfolders:
> 
>   %autosetup -c -n %{name}-%{commit}
>   cp -a %{name}-%{commit} %{name}-%{commit}-py2
>   ..
> 
> Note the -c and the lack of cd ../.
> 

That is *much* cleaner. I'll use this and see how it goes. Thanks.

-- 
Thanks,
Regards,

Ankur Sinha "FranciscoD"

https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1640572] Upgrade perl-Test-PostgreSQL to 1.27

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Test-PostgreSQL-1.27-1
   ||.fc30



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

Re: Fwd: Re: Vagrant: can we make it show up in Software?

[Vít Ondruch]

(Adding fedora-devel on CC)

The question is not how to do it but if we should do it on the first place.

I was always under impression, that we don't want to show CLI apps in
Software. Not sure what was the reasoning behind, but I can imagine that:

* we don't want Python to show up in Software (for example)

* screenshots of terminal window are not really attractive

Reading the AppData guidelines [1], it states several times something
like "If a package contains a GUI application" never mentions CLI. That
just strengthens my impression. So should we extend the guidelines to
support CLI apps?

Richard, what is your position on this (I know this started as a
reaction to your response).


Vít


[1] https://docs.fedoraproject.org/en-US/packaging-guidelines/AppData/



Dne 18. 10. 18 v 15:14 Matthew Miller napsal(a):
> See Richard's comments on how to do it. We could also bundle a desktop file
> which runs gnome-terminal...
>
> On Thu, Oct 18, 2018 at 02:51:38PM +0200, Vít Ondruch wrote:
>> Hi,
>>
>> It is not problem to make Vagrant show in Software. However, as far as i
>> know, CLI tools were never supposed to be there. If there was some UI
>> for Vagrant, that would be a different story an it could be shown in
>> Software. Unfortunately, I am not aware about any.
>>
>>
>> V.
>>
>>
>> Dne 18. 10. 18 v 14:25 Matthew Miller napsal(a):
>>> Hey, I see you're the main contact for Vagrant. Is this something you're
>>> interested in working on?
>>>
>>> - Forwarded message from Richard Hughes  -
>>>
 Date: Wed, 17 Oct 2018 10:30:55 +0100
 From: Richard Hughes 
 To: Discussions about development for the Fedora desktop

 Subject: Re: Vagrant: can we make it show up in Software?
 Archived-At: 
 

 On Wed, 17 Oct 2018 at 02:09, Matthew Miller  
 wrote:
> 1. Make vagrant available in software, or
 You can make random packages show up in software, although I think
 only codecs and fonts use this feature. To do it, just write a
 .metainfo.xml file (compnent type "generic"), and install it into
 /usr/share/metainfo -- although you'll need to also include an icon
 (which can be remote, e.g. https://foo.bar/baz.png), a screenshot and
 a (hopefully) translated name and long description.

 Richard.
 ___
 desktop mailing list -- desk...@lists.fedoraproject.org
 To unsubscribe send an email to desktop-le...@lists.fedoraproject.org
 Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
 List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
 List Archives: 
 https://lists.fedoraproject.org/archives/list/desk...@lists.fedoraproject.org
>>> - End forwarded message -
>>>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Johnny Robeson]

On Fri, 2018-10-19 at 03:43 +, Máirín Duffy wrote:
> I'm open to all of those suggestions as well as committing to design and CSS 
> work for them. I would need a web dev to help me though; I'm not great with 
> Django.
> 
> Please note, the reason Hyperkitty didn't cause this sort of thread or 
> honestly any sort of drama or controversy when it was deployed is because it 
> required no current users to change anything about their workflow, with one 
> small exception - mm3 didn't come out w topic support which was used on the 
> packagers list. (I don't believe that's an issue anymore.)
> 
> The whole point of the design was to enable a new group of would be 
> contributors be able to participate alongside the folks already there, so 
> that everyone could participate together. Existing ML users never need to use 
> Hyperkitty if they don't want to, and yet, users new to the project can start 
> reading and participating in threads right away w no mail client config and 
> never receiving a single email if they so desire. 
> 
> I believe quite strongly (and have from the start when I first heard of the 
> project) that Discourse's basic UX model is fundamentally flawed. If we 
> deploy discourse and roll it out, we *may* get new users, but as noted in 
> this thread, we will lose existing ones. Participating in upstream effort on 
> Discourse, improving it, etc is foolish bc the fundamental model is broken.
> 
> When some people think of email, they think of mutt or thunderbird, annoying 
> client config, setting up procmail or fetchmail or whatever other complex 
> elaborate tools many of the ppl reading this use. Email is just a basic 
> standard. Discourse does not follow that standard. There is no reason a 
> social media timeline like experience for the teenagers is not possible using 
> email as the underlying system. Jabber never really took off, except Google 
> Hangouts and FB messenger both used it (no idea if they still do.) The reason 
> our open standards like email and xmpp are dying off is bc the primary biz 
> model of the companies that used them relies on getting eyes on ads, and 
> scanning content in ways that mean giving users a choice of client that works 
> best for their needs is off the table.  

Can we be careful with association of timelines with teenagers here? It's a 
tiny bit belittling, and makes us all sound old and out of touch, since my 
parents (who are obviously older than me) know what they are. I've been using 
Linux exclusively on the desktop for a bit over 15 years, so you can guess I'm 
not a teen.

> Basically dont confuse the front end youre used to with the
> underlying tech.
> 
> I think it's a better idea to use a tool based on open standards,
> that allows users to use the client experience that works best for
> them. If you try to force everyone down one road it won't work. 
> 
> ~m
> ___
> devel mailing list -- 
> devel@lists.fedoraproject.org
> 
> To unsubscribe send an email to 
> devel-le...@lists.fedoraproject.org
> 
> Fedora Code of Conduct: 
> https://getfedora.org/code-of-conduct.html
> 
> 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1640572] Upgrade perl-Test-PostgreSQL to 1.27

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

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



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

Re: Empty debugsources.list file in build when enabling py2 builds

[Nicolas Mailhot]

> On 19.10.2018 00:28, Ankur Sinha wrote:
> > 
> > I'm still at a loss to why this is so. Would someone be able to shed
> > some light on this please?

That’s
https://github.com/rpm-software-management/rpm/issues/551

for bad old historical reasons the main directory rpmbuild works in is a
side-effect of %setup (which %autoseup calls behin the scenes), there’s
no way to override or even read in it %prep, and *many* bits of rpm
automation will look for stuff in this directory only.

Regards,

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

Re: how to detect Atomic Rawhide?

[Michal Novotny]

On Wed, Oct 17, 2018 at 9:18 AM Pavel Raiskup  wrote:
>
> On Tuesday, October 16, 2018 4:03:56 PM CEST Miroslav Suchý wrote:
> > Or should I do quick'n'dirty "if 'rawhide' in
> > os-release['REDHAT_BUGZILLA_PRODUCT_VERSION']" in our copr plugin?
>
> Or REDHAT_SUPPORT_PRODUCT_VERSION.
>
> I'd simply read one of those variables, or submit PR against
> 'fedora-release' package to add some new variable with clearer semantics.
> No other package seems to be able to do the clear cut at branching time.
>
> Note that dnf neither knows whether VERSION_ID=30 means rawhide nowadays
> ($releasever expands to 30), the only difference on Rawhide system is that
> fedora-repos-rawhide is installed && the repos enabled.  But one can have
> 'fedora-repos-rawhide' installed also on stable.

I'd like to suggest that on Rawhide, VERSION_ID=rawhide and VERSION=Rawhide,
which then makes distinction between rawhide and non-rawhide clear.

os-release specs
(https://www.freedesktop.org/software/systemd/man/os-release.html)
allow VERSION_ID to be a non-numeric string.

Rawhide is an actual Fedora version. It's a version of Fedora that provides
a continuous stream of packages and serves mainly development purposes
(nowadays?).

Additional (side) note:
Stuff like "Workstation Edition", "Server Edition" or "Atomic Host"
should probably
only go to VARIANT and VARIANT_ID because it's not a release code name like e.g.
"Beefy Miracle" was for Fedora 17.

We are overusing codename VERSION substring for things that are not codenames
but they are variants and a version.

clime (Michal Novotny)

M.

>
> Pavel
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora should replace mailing lists with Discourse

[Dominik 'Rathann' Mierzejewski]

Hi, Máirín.

On Friday, 19 October 2018 at 05:43, Máirín Duffy wrote:
[...] 
> I believe quite strongly (and have from the start when I first heard
> of the project) that Discourse's basic UX model is fundamentally
> flawed. If we deploy discourse and roll it out, we *may* get new
> users, but as noted in this thread, we will lose existing ones.
> Participating in upstream effort on Discourse, improving it, etc is
> foolish bc the fundamental model is broken.

Agreed. Well said.

[...]
> There is no reason a social media timeline like experience for the
> teenagers is not possible using email as the underlying system. Jabber
> never really took off, except Google Hangouts and FB messenger both
> used it (no idea if they still do.)

They used to, but no longer. Both have (d)evolved into their own
proprietary protocols. For FB, there's a plugin for pidgin/libpurple
that actually works quite well (purple-facebook package).

[...]
> I think it's a better idea to use a tool based on open standards, that
> allows users to use the client experience that works best for them. If
> you try to force everyone down one road it won't work. 

I fully agree.

If the company behind Discourse goes away for some reason and the
project is not picked up by community, we'll end up having to support it
ourselves and I don't think we have resources for this.

I don't think e-mail is going away anytime soon.

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

Re: Fedora should replace mailing lists with Discourse

[Marius Vollmer]

Randy Barlow  writes:

> On Wed, 2018-10-17 at 13:14 -0400, Matthew Miller wrote:
>> Discourse is *definitely* not a smooth, drop-in mailing list
>> replacement
>> like Hyperkitty is.
>
> I'm curious what is insufficient about Hyperkitty that Discourse does
> well at.

Badges, those are super important.  I already have the "First Emoji" and
"First Quote" badge on Discourse and I can't wait to get the "First Bold
Markup" one.

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

Re: Fedora should replace mailing lists with Discourse

[Dominik 'Rathann' Mierzejewski]

On Thursday, 18 October 2018 at 23:04, Gerald B. Cox wrote:
[...]
> I wouldn't expect it to be a "drop-in" mailing list replacement.
> Yes, it allows some backward compatibility by providing
> "mailing-list mode" - but you're going to get a richer
> experience if you use native interfaces.

So, I tried to answer in one of the threads and it's quite difficult,
in my opinion. The message compose pop-up doesn't quote the message
I'm replying to, so I can't write my comments in response to specific
passages by the previous person. Not being able to reply in context
is a deal-breaker to me. What do you call "a richer experience",
I wonder.

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

[389-devel] Nunc-stans status

[thierry bordaz]

Hi,

C10K is a scalability problem that a server can face when dealing with 
events of thousands of connections (i.e. clients) at the same time. 
Events can be new connections, new operations on the established 
connections, closure of connection (from client or server)


For 389-ds, C10K problem was resolved with a new framework *Nunc-Stans* 
[1]. Nunc-stans was first enabled in RHDS 7.4 and improved/fixed in 7.5. 
Robustness issues [2] and [3] were reported in 7.5 and it was decided to 
disable Nunc-stans. It is not known if those issues exist or not in 7.4.


William posted a PR to fix those two issues [4]. Nunc-stans is a complex 
framework, with its own dynamic. Review of this PR is not easy and even 
a careful review may not guaranty it will fix [2] and [3] and may not 
introduce others unexpected side effects.


From there we discussed two options (but there may be others):

1. Review and merge the PR [4], then later run some intensive tests
   aiming to verify [2],[3] and checking the robustness in order to
   reenable NS
2. Build some tests for
1. measure the benefit of NS as [2] and [3] do not prevent some
   performance tests
2. identify possible reproducers for [2] and [3]
3. create robustness and long duration NS specific tests
4. review and merge the PR [4]

As PR [4] is not intended for perf improvement, the step 2.1 will impact 
the priority according to the performance benefits.


Comments are welcomed


   Regarding 2.1 plan we made the following notes for the test plan:

   /The benefit of Nunc-Stans can only be measure with a large number
   of connections (i.e. client) above 1000. That means a set of clients
   (sometime all) should keep their connection //*opened*//. Clients
   should run on several hosts so that clients are not the bootleneck./

   /For the two types of events (new connection and new operations),
   the measurement could be/

 * /Event: New connections /
 o /Start all clients in parallel to establish connections
   (keeping them opened) take the duration to get 1000, 2000,
   ... 1 connections and check there are drop or not/
 o /Establish 1000 connections and monitor during to open 100
   more, the same starting with 2000, 1/
 o /Client should not run any operations during the monitoring/
 * /Event: New operations /
 o /Start all clients and when 1000 connections are
   established, launch simple operations (e.g. search -s base
   -b "" objectclass) and monitor how many of them can be
   handled. The same with 2000, ... 1./
 o /response time and workqueue length could be monitored to be
   sure the bottleneck are not the worker./

[1] http://www.port389.org/docs/389ds/design/nunc-stans.html

[2]https://bugzilla.redhat.com/show_bug.cgi?id=1608746 deadlock
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1605554 connection leaks

[4]https://pagure.io/389-ds-base/pull-request/49636

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

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

[Florian Weimer]

* Lennart Poettering:

> On Fr, 05.10.18 19:31, Kamil Paral (kpa...@redhat.com) wrote:
>
>> (cross-posting to devel and desktop lists, ideally reply to both)
>
> Coincidentally, at All Systems Go! in Berlin last week I had some
> discussions with kernel people about RLIMIT_NOFILE defaults. They
> basically suggested that the memory and performance cost of large
> numbers of fds on current kernels is cheap, and that we should bump
> the hard limit in systemd for all userspace processes.

Which kernel version is that?  Is that a new patch?  Or some older
kernel?

It's definitely not true for kernel 4.18, see the script I posted.

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

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

[Florian Weimer]

* Kamil Paral:

> From a technical point of view I'm not able to judge whether raising
> the fileno limits by default is a trivial change or something with
> important security implications.

It has implications for reliability (and perhaps security).  File
descriptors can refer to sockets, and each socket can have a fairly
large amount of unswappable kernel memory associated with it.  This
memory is not tracked along with the process that created the sockets or
has them opened, so the OOM killer does not take it into account when
selecting processes to terminate.

The attached script, when run with “python3 many-sockets.py 5” as a
regular user, after raising the limit, tricks the OOM killer into
terminating processes.  Important processes such as systemd-journal fail
because the OOM killer cannot recover any memory.  It even terminates
processes which are already fully swapped out.

I think a reasonable file descriptor limit is an important safety net.

Thanks,
Florian
import socket
import errno
import sys

count, = sys.argv[1:]
count = int(count)

blob = b"X" * 100
socket_list = [] # Keep all sockets open.
for n in range(count):
sockets = socket.socketpair(
socket.AF_UNIX, socket.SOCK_STREAM | socket.SOCK_NONBLOCK, 0)
for sock in sockets:
while True:
try:
sock.send(blob)
except BlockingIOError:
break
socket_list.append(sock)

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