Re: Self Introduction: Kairui Song

[Robin Lee]

On Fri, Jul 13, 2018 at 2:33 AM, Kairui Song  wrote:
> Hi all,
>
> I'm working on submitting a package, it's my first package. So I want to
> give a brief self-introduction here.
>
> My name is Kairui Song, I'm a software engineer at Red Hat, have been a Red
> Hat employee for two years, and start working on kdump / kexec and related
> components recently. Have been a Linux user/fan/enthusiast for about 4 years
> since college, started with customizing and optimize my smartphone's kernel.
> Besides this, I also have some experience working as a full-stack developer,
> and I enjoy learning and try all kinds of new things and tech stacks. I have
> a personal website, feel free to visit if you have any interest
> , there you can find my Github and some other social
> accounts.
>
> I'm seeking a sponsor for my package review request: (already approved)
> . I'm working with
> kexec-tools' package maintainer on splitting out a subpackage, please help
> if any sponsor is reading this, thank you!
Welcome!
Let's get in touch in the 中文 user group.[1]

[1] https://fedoraproject.org/wiki/Zh

-robin 李瑞彬
>
> ___
> 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/message/YR5WDDFVKKXO6ZJH72RXK3HNBBPHLOZ3/
>
___
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/message/FZBCN7Q5GC5B2FTJQGJVOXWZ2TEX3L5G/

Re: OCaml 4.07.0 is now in Fedora 29

[Jerry James]

On Thu, Jul 12, 2018 at 9:14 AM Jerry James  wrote:
> If I can, I will put my WIP mojo-executor,
> string-template-maven-plugin, and antlr4 packages somewhere online so
> any motivated souls can look at them while I am gone.  One thing that
> would help is to add a POM to the ant-contrib package; I had to do
> some ugly things in the mojo-executor package to work around its
> absence.  I will try to deal with all of this when I get back, but I
> would not be unhappy if some kind souls took care of some of this so I
> don't have to. :-)

Here is what I've got so far.  All of them can use a little more work.
If some kind Java-/maven-loving person would like to take these and
run with them, I would appreciate it very much.  Maven is not my
strong suit.

http://jamezone.org/pleasure/software/Fedora/mojo-executor-2.3.0-1.fc29.src.rpm
http://jamezone.org/pleasure/software/Fedora/string-template-maven-plugin-1.1-1.fc29.src.rpm
http://jamezone.org/pleasure/software/Fedora/antlr4-4.7.1-1.fc29.src.rpm

I will be mostly incommunicado for the next 8-9 days.  Regards,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/MVMVOQIALY3NEXYHGE3NXM2A7LFJBMLI/

[389-devel] 389 DS nightly 2018-07-13 - 90% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2018/07/13/report-389-ds-base-1.4.0.11-20180712git60cb520.fc28.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/HBSVR2ZD6FNRIGDWLFSKY6QAC444HLUL/

Re: Nonresponsive maintainer: thomasvs

[Miro Hrončok]

On 12.7.2018 23:38, Thomas Vander Stichele wrote:
For future reference, mail works great.  I've been behind due to travel 
and personal issues.



While I think this was a little quick to make a decision personally, I'm 
fine with someone else stepping in and taking over.


I followed a procedure [1].
Your last commit was 10 years ago, so I assumed you don't care anymore.

Nevertheless, you are still one of the admins of the package.

[1] 
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/WGWQN2HDMD45WBYSYKGTXYQIZKYWP26P/

Re: Nonresponsive maintainer: thomasvs

[Thomas Vander Stichele]

For future reference, mail works great.  I've been behind due to travel 
and personal issues.



While I think this was a little quick to make a decision personally, I'm 
fine with someone else stepping in and taking over.



Thomas


On 06/23/2018 07:37 AM, Miro Hrončok wrote:

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

Does anyone know how to contact the maintainer?


___
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/message/MTQSER5FRX6MQ355JFJPN4V2KWLPO7H2/

Re: Packages which use the BuildRoot: directive

[Jason L Tibbitts III]

> "MM" == Matthew Miller  writes:

MM> Yeah, this argument seems pretty compelling to me. I think that if
MM> people want to maintain an outside spec file, they *must* also
MM> respect changes made to the primary one in dist-git.

I took a break from this discussion, but I did want to point out that
the guideline itself does say pretty much exactly that:

"If some maintainers are also attempting to keep copies of a spec in an
outside repository, they MUST be prepared to merge changes made to the
spec in Fedora's repository, and MUST NOT overwrite those changes with a
copy from an external repository or using fedpkg import. "

We don't say that you can't maintain a copy externally, only that
Fedora's specfile is part of Fedora and that maintainers must expect
that Fedora will occasionally be modifying it.  Surely it isn't too much
to ask that those modifications not be wiped out.

 - J<
___
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/message/H4XCJGJCYYZITHN7CJET4BW56357BKFC/

Re: [HEADS UP] Removal of GCC from the buildroot

[Richard W.M. Jones]

On Thu, Jul 12, 2018 at 02:10:37PM -0400, Cole Robinson wrote:
> On 07/11/2018 04:37 PM, Kevin Fenzi wrote:
> > On 07/11/2018 12:57 PM, Mikolaj Izdebski wrote:
> >> On 07/11/2018 09:26 PM, Kevin Fenzi wrote:
> >>> I don't see the cache=unsafe anywhere (although the name sure makes me
> >>> want to enable it for official builds let me tell ya. ;) Can you point
> >>> out more closely where it is or docs for it?
> >>
> >> cache=unsafe is documented at [1]. (Basically, in virt_install_command
> >> you append ",cache=unsafe" to --disk parameter, next to "bus=virtio".)
> >> It makes buildvmhost cache all disk operations and ignore sync
> >> operations. Similar to nosync, but does not work on buildhw, works on
> >> virthost level, applies to all operations, not just dnf.
> >>
> >> [1]
> >> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/virtualization_tuning_and_optimization_guide/index#sect-Virtualization_Tuning_Optimization_Guide-BlockIO-Caching
> > 
> > Ah, I see at the vm level. Yeah, I don't think this would be very much
> > of a win for us. The x86_64 buildvm's have all their storage on iscsi,
> > the arm ones have their storage on ssd's. I suppose it could help the
> > ppc64{le} ones, they are on 10k sas drives. I'm pretty leary of enabling
> > anything called 'unsafe' though.
> 
> I think it's unsafe only in the case of on-disk consistency, so across
> VM reboots. I _think_ over a single run of a VM it's safe, which may
> describe koji usage.
> 
> I know rjones has looked deeply at qemu caching methods for use in
> libguestfs so maybe he can comment, CC'd

I cover caching modes about half way down here:

  
https://rwmj.wordpress.com/2013/09/02/new-in-libguestfs-allow-cache-mode-to-be-selected/

First off, cache=unsafe really does improve performance greatly, I
measured around 25% on a disk-heavy workload.

Does each build start with its own fresh VM?  Do you care about the
data in that build VM if either qemu or the host crashes?  If the
answers are 'Yes' and 'No' respectively to these questions then IMHO
this is the ideal situation for cache=unsafe.

The caveats:

If qemu or the host crashes, the disk image underlying these VMs will
(like 99.9% certainty) be corrupted.  Even 'sync' inside the VM will
not do what you expect, it is just ignored.  It's NOT a good idea on
VMs which are used for long periods when the host might reboot during
that time.  It's NOT a good idea if you deeply care about the data in
the disk image.

It should only be used when the VM data can be recreated from scratch.

In libguestfs we use cachemode.*unsafe in a few places, carefully
chosen, when the above conditions apply.
https://github.com/libguestfs/libguestfs/search?q=cachemode+unsafe_q=cachemode+unsafe

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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/message/CXOTYCK3WEZTRLBQTM7N3F4JGSOTZ2NR/

Re: Intel's Clear Linux optimizations

[Chris Murphy]

On Thu, Jul 12, 2018 at 10:09 AM, Manas Mangaonkar
 wrote:
> Rpm Generation Done, Sorry for the really long delay. Request someone to
> test it out.
>

URL?



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/UBETVVKZ3WMLRGTLF3IWQOADORTGHWRS/

Re: Fedora c++ default build flags

[mskalick]

Dan Horák píše v St 11. 07. 2018 v 14:12 +0200:
> On Wed, 11 Jul 2018 14:00:40 +0200
> mskal...@redhat.com wrote:
> 
> > Hi,
> > during a discussion with upstream (MongoDB) they asked me about
> > default Fedora C/C++ build flags. And I don't remember all Fedora
> > System Wide changes where it was introduced,... so is there some
> > place where it's described?
> 
> https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/bu
> ildflags.md
> 

Thanks. Also does someone have any information how our flags affects
performance?
(which is also important for the upstream project)

Thanks,
Marek

> 
>   Dan
> ___
> 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_guidelin
> es
> List Archives: https://lists.fedoraproject.org/archives/list/devel@li
> sts.fedoraproject.org/message/CDEM6BO4F5MIJONSF4G2GPMXRUK3GENE/
___
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/message/J5ZTRY6IVTIXN3XQ66QKMQCGTM3AJDAG/

Self Introduction: Kairui Song

[Kairui Song]

Hi all,

I'm working on submitting a package, it's my first package. So I want to
give a brief self-introduction here.

My name is Kairui Song, I'm a software engineer at Red Hat, have been a Red
Hat employee for two years, and start working on kdump / kexec and related
components recently. Have been a Linux user/fan/enthusiast for about 4
years since college, started with customizing and optimize my smartphone's
kernel. Besides this, I also have some experience working as a full-stack
developer, and I enjoy learning and try all kinds of new things and tech
stacks. I have a personal website, feel free to visit if you have any
interest , there you can find my Github and some
other social accounts.

I'm seeking a sponsor for my package review request: (already approved) <
https://bugzilla.redhat.com/show_bug.cgi?id=1599666>. I'm working with
kexec-tools' package maintainer on splitting out a subpackage, please help
if any sponsor is reading this, 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/message/YR5WDDFVKKXO6ZJH72RXK3HNBBPHLOZ3/

Re: [HEADS UP] Removal of GCC from the buildroot

[Cole Robinson]

On 07/11/2018 04:37 PM, Kevin Fenzi wrote:
> On 07/11/2018 12:57 PM, Mikolaj Izdebski wrote:
>> On 07/11/2018 09:26 PM, Kevin Fenzi wrote:
>>> On 07/11/2018 10:53 AM, Mikolaj Izdebski wrote:
 On 07/11/2018 07:31 PM, Andrew Lutomirski wrote:
> On Wed, Jul 11, 2018 at 10:08 AM, Mikolaj Izdebski  
> wrote:
>>
>> The slowest parts of setting up chroot is writing packages to disk,
>> synchronously. This part can be speeded up a lot by enabling nosync in
>> site-defaults.cfg mock config on Koji builders, setting cache=unsafe on
>> kvm buildvms, or both. These settings are safe because builders upload
>> all results to hubs upon task completion. With these settings chroot
>> setup can take about 30 seconds.
>
>
> I don't suppose this could get done?

 I proposed this a few years ago, but the answer was "no".
>>>
>>> I think the reason why releng didn't want to do that is because we don't
>>> want to trade speed for reliability. True, we don't care if a machine
>>> crashes in the middle of a build (because another one will take it after
>>> the crashed one comes back), but we don't want to change anything that
>>> might affect the actual build artifacts.
>>>
>>> So, are we sure that nosync (disabling all fsync calls) doesn't change
>>> the builds being made? What about test suites for packages that
>>> specifically call fsync? They would always pass even if there was a
>>> problem?
>>
>> nosync is used by mock only for running dnf(/yum). It's not used for
>> rpmbuild nor runroot, so it won't affect package tests. It could
>> theoretically affect scriplets ran during package installation, but I've
>> been using nosync in all my Koji instances for a few years and I didn't
>> see any problems. Nosync is used in Copr and I didn't get any reports
>> about it breaking anything. Recently, to test the change in subject,
>> Igor Gnatenko did a few Fedora rebuilds a Koji set up by me, of course
>> with nosync enabled, and I didn't see any problems related to nosync either.
>>
>>> We could try this in staging I suppose and have koschei run a
>>> ton of builds to see what breaks...
>>
>> I would really like that.
> 
> I'd say open a releng ticket on it and we can track it there?
> This sounds like it might be worth doing...
> 
> 
>>> I don't see the cache=unsafe anywhere (although the name sure makes me
>>> want to enable it for official builds let me tell ya. ;) Can you point
>>> out more closely where it is or docs for it?
>>
>> cache=unsafe is documented at [1]. (Basically, in virt_install_command
>> you append ",cache=unsafe" to --disk parameter, next to "bus=virtio".)
>> It makes buildvmhost cache all disk operations and ignore sync
>> operations. Similar to nosync, but does not work on buildhw, works on
>> virthost level, applies to all operations, not just dnf.
>>
>> [1]
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/virtualization_tuning_and_optimization_guide/index#sect-Virtualization_Tuning_Optimization_Guide-BlockIO-Caching
> 
> Ah, I see at the vm level. Yeah, I don't think this would be very much
> of a win for us. The x86_64 buildvm's have all their storage on iscsi,
> the arm ones have their storage on ssd's. I suppose it could help the
> ppc64{le} ones, they are on 10k sas drives. I'm pretty leary of enabling
> anything called 'unsafe' though.

I think it's unsafe only in the case of on-disk consistency, so across
VM reboots. I _think_ over a single run of a VM it's safe, which may
describe koji usage.

I know rjones has looked deeply at qemu caching methods for use in
libguestfs so maybe he can comment, CC'd

- Cole
___
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/message/Z7WFGD3GD5ZWJNSEB3ZG63GJAYT2HR67/

Re: Fedora 29 Mass Rebuild

[Mohan Boddu]

Hi all,

Things got fixed quicker than expected. The issues related to binutils is
fixed
with binutils-2.30.90-3.fc29 build.

So, we will be starting mass rebuilds today, that is Jul 12th 2018.

Fun note: Due to a day of delay in mass rebuilds, we were able to get OCaml
4.07
change into F29.

Thanks,
Fedora Release Engineering.

On Wed, Jul 11, 2018 at 1:55 PM Mohan Boddu  wrote:

> Hi all,
>
> We are delaying the mass rebuild as people are still working on
> binutils 2.31 change (https://fedoraproject.org/wiki/Changes/BINUTILS231).
>
> At this point, we want to re-evaluate the situation on Friday, 13 July
> 2018 and
> based on where we are, we will either proceed with the mass rebuild or we
> might
> delay it further.
>
> The two issues that we are currently aware of are:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1599441
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1600035
>
> We will keep you updated if anything changes.
>
> Thanks,
> Fedora Release Engineering.
>
> On Fri, Jul 6, 2018 at 9:29 AM Mohan Boddu  wrote:
>
>> Hi all,
>>
>> Per the Fedora 29 schedule[1] we will be starting a mass rebuild for
>> Fedora 29 very shortly. We are doing a mass rebuild for Fedora 29 for all
>> the changes listed in
>>
>> https://pagure.io/releng/issue/7480
>>
>> we will start the mass rebuild on 2018-07-11
>>
>> This is a heads up that it will be done in a side tag and moved over
>> when completed. We will be running scripts to output failure stats.
>> please be sure to let releng know if you see any bugs in the reporting.
>>
>> You can contact releng in #fedora-releng on freenode.
>>
>> Failures can be seen
>>
>> https://kojipkgs.fedoraproject.org/mass-rebuild/f29-failures.html
>>
>> Things still needing rebuilt
>>
>> https://kojipkgs.fedoraproject.org/mass-rebuild/f29-need-rebuild.html
>>
>> Regards
>>
>> Mohan Boddu
>>
>
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org/message/GWGDLAHMJMPYBEPNLF3X4XQHMW5MYAM5/
___
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/message/GWGDLAHMJMPYBEPNLF3X4XQHMW5MYAM5/

Re: Fedora 29 Mass Rebuild

[Mohan Boddu]

Hi all,

Things got fixed quicker than expected. The issues related to binutils is
fixed
with binutils-2.30.90-3.fc29 build.

So, we will be starting mass rebuilds today, that is Jul 12th 2018.

Fun note: Due to a day of delay in mass rebuilds, we were able to get OCaml
4.07
change into F29.

Thanks,
Fedora Release Engineering.

On Wed, Jul 11, 2018 at 1:55 PM Mohan Boddu  wrote:

> Hi all,
>
> We are delaying the mass rebuild as people are still working on
> binutils 2.31 change (https://fedoraproject.org/wiki/Changes/BINUTILS231).
>
> At this point, we want to re-evaluate the situation on Friday, 13 July
> 2018 and
> based on where we are, we will either proceed with the mass rebuild or we
> might
> delay it further.
>
> The two issues that we are currently aware of are:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1599441
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1600035
>
> We will keep you updated if anything changes.
>
> Thanks,
> Fedora Release Engineering.
>
> On Fri, Jul 6, 2018 at 9:29 AM Mohan Boddu  wrote:
>
>> Hi all,
>>
>> Per the Fedora 29 schedule[1] we will be starting a mass rebuild for
>> Fedora 29 very shortly. We are doing a mass rebuild for Fedora 29 for all
>> the changes listed in
>>
>> https://pagure.io/releng/issue/7480
>>
>> we will start the mass rebuild on 2018-07-11
>>
>> This is a heads up that it will be done in a side tag and moved over
>> when completed. We will be running scripts to output failure stats.
>> please be sure to let releng know if you see any bugs in the reporting.
>>
>> You can contact releng in #fedora-releng on freenode.
>>
>> Failures can be seen
>>
>> https://kojipkgs.fedoraproject.org/mass-rebuild/f29-failures.html
>>
>> Things still needing rebuilt
>>
>> https://kojipkgs.fedoraproject.org/mass-rebuild/f29-need-rebuild.html
>>
>> Regards
>>
>> Mohan Boddu
>>
>
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-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/devel-announce@lists.fedoraproject.org/message/GWGDLAHMJMPYBEPNLF3X4XQHMW5MYAM5/

Re: Packages which use the BuildRoot: directive

[R P Herrold]

On Thu, 12 Jul 2018, Miro Hrončok wrote:

> > > The guidelines currently say:

Are these Holy Writ, or just process, subject to amendment?

> > > I think this guideline is bad and counterproductive, since many
> > > packages clearly ignore it.

There is a principle:

Seek first to understand

before ** suggesting ** what one feels are helpful suggestions

It applies here

> > > So what do we do? Take the package away from
> > > (most likely) upstream developers? 

oh -- So forking, or adding (probably) unwanted 
co-maintainers, or continuing to fight that entropy with 
what are functionally an unknown number of 'provenpackagers' 
co-maintainers, pushing unwanted 'fixes' in, is proposed?


and a peeve:  NOT updating the changelog when literally 
thousands of packages are re-factored?  I know I always love 
getting to play detective, when an encountered version does not 
match a prior SRPM of the same NEVR

> > > Tell them no no no very sternly so
> > > they can ignore us?

If being ignored bothers you, perhaps the problem is not them, 
but your reaction at being ignored

Perhaps offer of the carrot rather than use of the stick is in 
order.  Maybe, just asking questions, and coming up with a 
rubric to annotate within a non-parsed field in a .spec file 
where 'upstream' is (as was suggested -- as was done with the 
various side adjunct repos -- dag, RF, more, to accommodate 
their tooling)

> > projects. So we do have leverage.

great -- using force always makes new friends ... NOT

What happened to the Four Fedora F's ?

> always a Red Hat maintained software, where people were 
> basically telling us: "no, we won't accept your PR here, we 
> maintain the specfile somewhere else".

'Always'? A fork of 'Spacewalk' just left because of the 
non-public approach to road-map by Red Hat insiders, and simply 
ignoring or not taking non @redhat commits.  I spoke with Don 
Vosburg of SUSE at a conference about his frustration with 
having to do so just a week or two ago.  He _wished_ the fork 
was not required, but to maintain the their implementation, 
which is productized as 'SUSE Manager', he had to get that 
fixes in

See again, seeking to understand first before suggesting 
prescriptions to the person ** volunteering ** to do work 
which happens also to benefit the Fedoraproject

The project is a social voluntary organization -- driving 
volunteers AWAY is trivially easy.  I took heat in the CentOS 
project for working to keep the Signal to Noise ratio high, at 
the expense of intentionally (and by a rubric documented in 
the CentOS wiki) removing people unwilling to play by that set 
of rules.  I'd do it the same way again tomorrow.  But I knew 
I was not being welcoming to all, as not all were welcome, 
frankly.  Immediate kick-bans of people using profanity, 
racist content, etc, seem to be a win to me

> It was very unpleasant experience and usually such maintainers expects us to:

Again, the location of the hurt feelings is not with the 
remote maintainer.  Examining ** why ** you feel that way is 
in order.  Perhaps an out of band discussion with the 
recalcitrant offender is in order ;)  Looking at my sent 
folder, I see that I send 20 to 30 'off list' emails a month, 
to get at the reasoning of another behind things I do not 
understand


I find that it is very unpleasant to encounter a auto-closed 
bug, doing research as to an error, and knowing full well that 
this close is saying:

This bug (and the current item I am researching) is 
known, but we did not fix it, so we swept it under the rug.  
Perhaps it will fix itself

At that point, I can solve my unhappiness by:

committing a local fix, and NOT upstreaming it
- or -
committing a local fix, and upstreaming it

Obviously one path is better than the other for 'improving the 
breed' -- but if I have been filing ignored bugs, which 
simply get auto-closed, it is easier to do less work

> Some maintainers were kinder than others, taking the changes and applying them
> in their god-knows-where maintained spec files. Some where not.

And, frankly, that is their choice to make, rather than yours, 
unless you are proposing to excommunicate people from 
Fedoraproject

> We don't need to make the rule less strict, we need to find a way to enforce
> it. The current state (people ignoring this rule) makes contributing to Fedora
> even harder than it already is.

"The beatings will continue until morale improves"  

kindly, 

-- 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/message/QMHUKQNSCP65XNYWJOJREXQDDAQIKSEM/

Re: Packages which use the BuildRoot: directive

[Ken Dreyer]

On Wed, Jul 11, 2018 at 11:39 AM, Ben Rosser  wrote:
> We have been telling people for a while now that they don't "own"
> their packages. Making it easier for people to maintain their packages
> outside of dist-git and (effectively) ignore changes from
> proven-packagers seems to take us in the opposite direction.

I don't think I agree with the messaging that people don't "own" their
packages. I get the point that people should be open to other
contributors changing things, like the original context of this
thread. On the other hand, people don't take pride in work if they
don't "own" it :) We want to bring more contributors into Fedora, and
there's an element of pride in becoming a package maintainer that's a
good community incentive.

- Ken
___
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/message/K27PQCIBIKRIIAZDUD6CTH4X6HVDKL3B/

Re: Haskell failures: relocation refers to local symbol "" [1], which is defined in a discarded section

[Florian Weimer]

On 07/12/2018 10:44 AM, Florian Weimer wrote:

On 07/12/2018 02:04 AM, Elliott Sales de Andrade wrote:
Does anyone know what's going on here? Is is annobin, new binutils, 
something else? The earliest failing build I can find is git-annex 
[3], and the dependency changes show annobin, binutils, and glibc 
(among others.)


It's a change in the glibc startup code, which triggers something which 
looks like a bug in the gold linker.  I filed a non-Haskell reproducer 
here:


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


Nick patched binutils, and I rebuilt ghc-optional-args-1.0.2-1.fc29 
without failure, so this should be fixed now.


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/message/4DH5RA34P26E6OT4KZHBIIBZ4PX2LVHG/

Packages needlessly use __provides_exclude_from on python sitearch

[Miro Hrončok]

There are 56 packages that use something like this:

%global __provides_exclude_from ^(%{python_sitearch}/.*\\.so)$
%global __provides_exclude_from ^(%{python2_sitearch}/.*\\.so)$
%global __provides_exclude_from ^(%{python3_sitearch}/.*\\.so)$
%global __provides_exclude_from 
^(%{python2_sitearch}|%{python3_sitearch})/.*\\.so$

...

and 68 like this:

%filter_provides_in %{python_sitearch}/whatnot/.*\.so$
%filter_provides_in %{python2_sitearch}/.*\.so$
%filter_provides_in %{python2_sitearch}/.*\.so$ %{python3_sitearch}/.*\.so$
...

The full list can be obtained by:

$ rg '(filter_provides_in|__provides_exclude_from).*python'

This is not needed in Fedora and EPEL7. It is needed in EPEL6 only, but 
EPEL6 doesn't have __provides_exclude_from.


I intent to mass change the 56 packages to remove it.
I'll keep the %filter_provides_in ones, because people might have it for 
el6 compatibility.



List of packages using __provides_exclude_from python*_sitearch:

(You can fix them, but I'll do it anyway (unless you tell me not to), no 
changelog entry or release bump needed.)



Maintainers by package:
NLoptbesser82
PyQt4rdieter than
PyQwttadej
botanthm
gdal alexlan devrim jmlich mmahut oliver orion pali 
praiskup volter

gfal2-python aalvarez adev andreamanzi
groonga  kenhys myokoym
iscsi-initiator-utils cleech grover jwrdegoede
libbatch smani
libemu   rebus
libgpod  alexl caillon caolanm chkr johnp limb mbarnes 
moezroy rhughes rstrode ssp teuf tpokorra

libkml   smani
libpwquality tmraz
libssh2-python   clalance
libuser  herczy jhrozek mitr
mpi4py   deji tomspur
nordugrid-arcellert jonkni
openbabelitamarjp jussilehtola rathann
py-bcryptkevin limb
pygrib   jdekloe
pykde4   jreznik rdieter than
pyproj   jdekloe
python-MDAnalysisrathann
python-Traitsignatenkobrain orion
python-alsa  limb perex
python-cassandra-driver filabrazilska lbalhar lkundrak praiskup
python-cffi  brouhaha jdulaney
python-cpopenbronhaim danken dougsland
python-djvulibre bstinson
python-dulwich   fab
python-geventdcallagh goldmann ignatenkobrain orion skottler
python-msgpack   dfateyev fab ktdreyer pjp sundaram
python-nss   jdennis
python-numexpr   tnorth zbyszek
python-pandaskushal orion sergiopr wakko666
python-pillowmiminar smani
python-plyveldcallagh
python-psutilsalimma
python-pymilter  pwouters sdgathman
python-rpi-gpio  fab kushal
python-scikit-learn  besser82 ignatenkobrain lupinix sergiopr
python-scss  mrunge puiterwijk
python-simplejsonfschwarz kylev lmacken mrunge
python-sqlalchemybowlofeggs ivazquez lmacken nphilipp
python-tinycss   brouhaha
python-zmq   ralph tomspur
qgis bruno daveisfera volter
qpid-cpp irina nsantos
rb_libtorrentfale orphan
root ellert
saga volter
sssd abbra asn fidencio jhrozek sbose simo
thrift   ctubbsii milleruntime willb
tomoe-gtkdchen
vtk  athimm jgu mrceresa orion
xpra jgu sagitter sergiomb

Packages by maintainer:
aalvarez   gfal2-python
abbra  sssd
adev   gfal2-python
alexl  libgpod
alexlangdal
andreamanzi gfal2-python
asnsssd
athimm vtk
besser82   NLopt python-scikit-learn
bowlofeggs python-sqlalchemy
bronhaim   python-cpopen
brouhaha   python-cffi python-tinycss
bruno  qgis
bstinson   python-djvulibre
caillonlibgpod
caolanmlibgpod
chkr   libgpod
clalance   libssh2-python
cleech iscsi-initiator-utils
ctubbsii   thrift
danken python-cpopen
daveisfera qgis
dcallagh   python-gevent python-plyvel
dchen  tomoe-gtk
deji   mpi4py
devrim gdal
dfateyev   python-msgpack
dougsland  python-cpopen
ellert nordugrid-arc root
fabpython-dulwich python-msgpack python-rpi-gpio
fale   rb_libtorrent
fidencio   sssd
filabrazilska python-cassandra-driver
fschwarz   python-simplejson
goldmann   python-gevent
grover iscsi-initiator-utils
herczy libuser
ignatenkobrain python-Traits python-gevent python-scikit-learn
irina  qpid-cpp
itamarjp   openbabel
ivazquez   python-sqlalchemy
jdekloepygrib pyproj
jdennispython-nss
jdulaney   python-cffi
jguvtk xpra
jhrozeklibuser sssd
jmlich gdal
johnp  libgpod
jonkni nordugrid-arc
jreznikpykde4
jussilehtola openbabel
jwrdegoede iscsi-initiator-utils
kenhys groonga
kevin  py-bcrypt
ktdreyer   python-msgpack
kushal python-pandas python-rpi-gpio
kylev  python-simplejson
lbalharpython-cassandra-driver
limb   libgpod py-bcrypt python-alsa
lkundrak   python-cassandra-driver
lmackenpython-simplejson python-sqlalchemy
lupinix 

corsepiu pushed to perl-Type-Tie (master). "Upstream update."

[notifications]

Notification time stamped 2018-07-12 16:18:12 UTC

From f300d5c4a6e553795aa53f2f4f3905d1452a532d Mon Sep 17 00:00:00 2001
From: Ralf Corsépius 
Date: Jul 12 2018 16:18:03 +
Subject: Upstream update.


---

diff --git a/.gitignore b/.gitignore
index 3fc0104..395f573 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/Type-Tie-0.009.tar.gz
+/Type-Tie-0.011.tar.gz
diff --git a/perl-Type-Tie.spec b/perl-Type-Tie.spec
index 865f278..3d71b20 100644
--- a/perl-Type-Tie.spec
+++ b/perl-Type-Tie.spec
@@ -1,6 +1,6 @@
 Name:   perl-Type-Tie
-Version:0.009
-Release:8%{?dist}
+Version:0.011
+Release:1%{?dist}
 Summary:Tie a variable to a type constraint
 # cf. README
 License:GPL+ or Artistic
@@ -34,6 +34,7 @@ BuildRequires:  perl(MooseX::Types::Moose)
 BuildRequires:  perl(Test::Fatal)
 BuildRequires:  perl(Test::More) >= 0.96
 BuildRequires:  perl(Test::Requires)
+BuildRequires:  perl(Try::Tiny)
 BuildRequires:  perl(constant)
 
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
@@ -51,6 +52,9 @@ the variable conform.
 %prep
 %setup -q -n Type-Tie-%{version}
 
+# Remove bundled stuff
+%{__rm} -r inc/
+
 %build
 %{__perl} Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
 %{__make} %{?_smp_mflags}
@@ -70,6 +74,9 @@ the variable conform.
 %{_mandir}/man3/*
 
 %changelog
+* Thu Jul 12 2018 Ralf Corsépius  - 0.011-1
+- Upstream update.
+
 * Sat Jun 30 2018 Jitka Plesnikova  - 0.009-8
 - Perl 5.28 re-rebuild of bootstrapped packages
 
diff --git a/sources b/sources
index 8ce5b41..222e822 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-SHA512 (Type-Tie-0.009.tar.gz) = 
2c416cd22d1d4a7ec902470d0801d479a54f312d456982e51671ba7391d127297471f0f753df5cafef4b6e01c983cd9f8f69c99f03f571aad5c89036c642a6c6
+SHA512 (Type-Tie-0.011.tar.gz) = 
ce4de19c14c46066e9b58cb13cf9ac4c108f99b8db604e9d8766168193b2e617e92bccc9f27fadd96f7103eae3a380c2041087b451239d713b7ce02eac202d43



https://src.fedoraproject.org/rpms/perl-Type-Tie/c/f300d5c4a6e553795aa53f2f4f3905d1452a532d?branch=master
___
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/message/KQSOMBR6JXN5YVPVMBRVGEU2EK5M2WLE/

Re: Intel's Clear Linux optimizations

[Manas Mangaonkar]

Rpm Generation Done, Sorry for the really long delay. Request someone to
test it out.



On Mon, Jun 18, 2018 at 4:54 PM, Manas Mangaonkar  wrote:

> Just a update,Ended up with a somewhat broken kernel that had performance
> issues with the lts patches even after lot of tweaking.Apparently the clear
> linux base kernel source tree is stable and working with latest Linux
> kernels. Still working on it incase anyone is wondering if this was
> abandoned.
>
> On Tue, May 22, 2018 at 11:48 AM, Manas Mangaonkar <
> manasmangaon...@gmail.com> wrote:
>
>>
>> >The upstream non LTS kernels have had the mitigation for
>>> >meltdown/spectre longer than LTS and they likely have more robust
>>> >implementations. All Fedora releases have had fixes for some time.
>>>
>>
>> I meant the clear linux kernel,they seem to have diff kernel bundles
>> and i want to go with the Lts one.
>>
>>
>>>
>>> > To get your feet wet, you could build a standard Fedora kernel using
>>> > one of these processes.
>>> >
>>> > https://fedoraproject.org/wiki/Building_a_custom_kernel
>>> >
>>> > https://docs.fedoraproject.org/quick-docs/en-US/kernel/build
>>> -custom-kernel.html
>>> >
>>> > https://fedoraproject.org/wiki/Building_a_custom_kernel/Source_RPM
>>> >
>>> > Then, when you have that working, use the same procedure to build the
>>> > clear linux kernel from source.  That way you know that both compile
>>> > individually.
>>> >
>>> > The final step is just to ensure that once the Fedora kernel is patched
>>> > to support clear linux, it compiles also.  Then it will support the
>>> > Fedora enhancements to the kernel that haven't made it upstream yet
>>> > (and might never), and will run on any fedora system.
>>> >
>>> > I don't know if the clear linux kernel is compatible with other
>>> > architectures and video hardware.  If it isn't, it can only be run on
>>> > x86_64 with intel video hardware (no nvidia or amd additional video
>>> > hardware).  If it isn't compatible with other architectures or video
>>> > hardware, I don't think it makes sense to compile it as a Fedora
>>> > kernel, so you would be done after you get it building from source.
>>> > Not sure how useful such a kernel would be.
>>> > ___
>>> > 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.or
>>> g/archives/list/devel@lists.fedoraproject.org/message/SDS3J7
>>> 23DDZB6VNXHD2DVD2STHC7TDSY/
>>> ___
>>> 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.or
>>> g/archives/list/devel@lists.fedoraproject.org/message/BA3RBX
>>> Y3PYJ4U2H5LCLJ6ZWTX4FITDGS/
>>
>>
>> The clear linux does run on amd hardware,at phoronix they tried it on the
>> new eypec cpu line from amd. Performs well and wont hinder performance.
>>
>> > hardware, I don't think it makes sense to compile it as a Fedora
>> > kernel, so you would be done after you get it building from source.
>> > Not sure how useful such a kernel would be.
>>
>> No nvidia or amd gpu support though.But for those who want pure computing
>> power for containers etc this can be a solid option,it does perform much
>> better than other linux distro kernels.
>>
>> I find this interesting,and a fun learning experience to get my feet wet.
>>
>
>
___
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/message/OJ3ZWGIV3UDMRUWCZBTB3V2FOEM7B222/

Re: [HEADS UP] Removal of GCC from the buildroot

[Mikolaj Izdebski]

On 07/11/2018 10:27 PM, Zbigniew Jędrzejewski-Szmek wrote:
> The effects of fsync are impossible to see unless you hard-reboot the
> machine. (OK, strictly speaking, you can time the fsync call, but let's
> ignore that). I'd be more worried about some side-effects of the way
> that nosync is implemented with a LD_PRELOAD. I wonder if it wouldn't be
> more robust to use nspawn's syscall filter to filter the fsync calls.
> (If nspawn is already used by koji, not sure.)

Koji does not use systemd-nspawn. It uses plain old chroot.

-- 
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
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/message/DJTKXBUZAEX2C3YSQKDCSG6PQG7VMIXP/

Re: OCaml 4.07.0 is now in Fedora 29

[Jerry James]

On Thu, Jul 12, 2018 at 8:42 AM Richard W.M. Jones  wrote:
> OCaml 4.07.0 was released on Tuesday and it's in Fedora Rawhide today.
> All packages that use OCaml have been recompiled except:
>
>  - why3: "Error: Unbound module Stdlib" - probably needs an
>upstream change
>
> If you see any other problems related to OCaml compilation with the
> new package then let me know.

There is a new version of why3 available, but it needs a new version
of coq.  And the new version of coq needs the python 3 runtime library
for antlr 4.7.1.  We have antlr 4.5.2 in Fedora, and only the Java
runtime library.  So I'm kind of stuck right now until the antlr4
maintainer has time to look at
https://bugzilla.redhat.com/show_bug.cgi?id=1599015.  He seems like a
very busy guy.

In just a few hours, I am heading into a situation where I will be
(mostly) cut off from the public Internet for about a week and a half,
so I can't do anything about any of this for a little while.  I have
worked out how to package 2 new dependencies for antlr 4.7.1
(mojo-executor and string-template-maven-plugin), and have also worked
out how to change the antlr4 spec to provide the python 3 runtime
library.  Honestly, we should probably rework the antlr4 package so
that it provides as many language runtimes as possible, but that
brings up the awkward situation of a noarch (Java) main package with
archful subpackages (like the C++ runtime).

If I can, I will put my WIP mojo-executor,
string-template-maven-plugin, and antlr4 packages somewhere online so
any motivated souls can look at them while I am gone.  One thing that
would help is to add a POM to the ant-contrib package; I had to do
some ugly things in the mojo-executor package to work around its
absence.  I will try to deal with all of this when I get back, but I
would not be unhappy if some kind souls took care of some of this so I
don't have to. :-)

Regards,
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/OUQ6ZXNVYBPUNHYOQS3VES23LM6RU6US/

[389-devel] please review: PR 49849 - Fix issues found in snmp MIB file

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/49849
___
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/message/EJB4YJ5BX34535SLHVI655NMUYQDPQKL/

Re: OCaml 4.07.0 is now in Fedora 29

[Richard W.M. Jones]

On Thu, Jul 12, 2018 at 03:40:34PM +0100, Richard W.M. Jones wrote:
> OCaml 4.07.0 was released on Tuesday and it's in Fedora Rawhide today.
> All packages that use OCaml have been recompiled except:
> 
>  - why3: "Error: Unbound module Stdlib" - probably needs an
>upstream change

A couple more actually:

 - plplot: Failed to build with an unrelated Python2 error.  I suspect
   we need to add ‘BuildRequires: python-unversioned-command’ but
   I did not change anything.

 - ocamlmod & ocaml-oasis: https://bugzilla.redhat.com/show_bug.cgi?id=1600596

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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/message/NNN2WGKJVCY3KU3MPRL2RNNL7ZBUBEX2/

Re: Packages which use the BuildRoot: directive

[Miro Hrončok]

On 12.7.2018 00:11, Zbigniew Jędrzejewski-Szmek wrote:

On Wed, Jul 11, 2018 at 12:47:40PM -0700, Kevin Fenzi wrote:

The guidelines currently say:

https://fedoraproject.org/wiki/Packaging:Guidelines#Spec_Maintenance_and_Canonicity

"Fedora's git repository is the canonical location for Fedora spec
files. Maintainers MUST expect that other maintainers and automated
tooling will make changes to their packages, potentially without
communicating prior to doing so (though communication is always
encouraged). If some maintainers are also attempting to keep copies of a
spec in an outside repository, they MUST be prepared to merge changes
made to the spec in Fedora's repository, and MUST NOT overwrite those
changes with a copy from an external repository or using fedpkg import."

I think this guideline is bad and counterproduuctive, since many
packages clearly ignore it.

It would be "counterproductive" if it increased the occurrence of the
unwanted thing. If it's sometimes ignored, sometimes not, it's not
counterproductive, but maybe not as effective as (some) would like.


So what do we do? Take the package away from
(most likely) upstream developers? Tell them no no no very sternly so
they can ignore us?

Actually I think this setup is more often used by projects that are
Fedora-only or RHEL-and-Fedora-only, than fully independent upstream
projects. So we do have leverage.


I second that. When we mass filled PRs with python2 related changes it 
was always a Red Hat maintained software, where people were basically 
telling us: "no, we won't accept your PR here, we maintain the specfile 
somewhere else". It was very unpleasant experience and usually such 
maintainers expects us to:


 1) find their canonical spec file location and figure out what special 
branch we need to apply the patch to


 2) wait for a new release of their software to happen and specfile 
changes be "backported" into Fedora (sometimes took months)


Some maintainers were kinder than others, taking the changes and 
applying them in their god-knows-where mainained spec files. Some where not.


We don't need to make the rule less strict, we need to find a way to 
enforce it. The current state (people ignoring this rule) makes 
contributing to Fedora even harder than it already is.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/CAAVYJILILR2VJKUJXTL64CK6BI3UNIW/

OCaml 4.07.0 is now in Fedora 29

[Richard W.M. Jones]

OCaml 4.07.0 was released on Tuesday and it's in Fedora Rawhide today.
All packages that use OCaml have been recompiled except:

 - why3: "Error: Unbound module Stdlib" - probably needs an
   upstream change

If you see any other problems related to OCaml compilation with the
new package then let me know.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
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/message/QFU2CE7AUQJIQRMM6LCA4WDQ47CJ3CKN/

[Bug 1594610] perl-File-Temp-0.2306 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-File-Temp-0.230.600-1.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/message/CVW773QXBKTTK4BTCOIE2VSENVCAHDLO/

[Bug 1597276] perl-Test-POE-Client-TCP-1.18 is available

[bugzilla]

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



--- Comment #7 from Fedora Update System  ---
perl-Test-POE-Client-TCP-1.18-1.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/message/NLNIU3S2YN4Q4NU5BXHI27VYQ42UW3E4/

[Bug 1597276] perl-Test-POE-Client-TCP-1.18 is available

[bugzilla]

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



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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/message/JGBOKAEEB3IV2M6YD6FW2WENADOP6GRD/

[Bug 1594610] perl-File-Temp-0.2306 is available

[bugzilla]

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



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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
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/message/42BCHOOXVTFGBNCAIJQOYW27TVOKCIPG/

Re: [HEADS UP] Removal of GCC from the buildroot

[Chris Adams]

Once upon a time, Petr Pisar  said:
> On 2018-07-11, Zbigniew Jędrzejewski-Szmek  wrote:
> > The effects of fsync are impossible to see unless you hard-reboot the
> > machine.
> 
> Are you sure non-fsynced changes are are guaranteed to be visible on
> block cache level? E.g. if you mix read/write and mmaped I/O from
> different processes?

fsync() has nothing to do with that - it is purely a request to push the
buffer to disk.  There is nothing defined about fsync() that would
affect inter-process I/O.

http://pubs.opengroup.org/onlinepubs/009695299/functions/fsync.html

-- 
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/message/LLOYZU75JTFBA2V63QGDVHABVJ37VXQQ/

[Bug 1600504] New: Bad license tag

[bugzilla]

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

Bug ID: 1600504
   Summary: Bad license tag
   Product: Fedora
   Version: 27
 Component: perl-DateTime-Format-Builder
  Assignee: p...@city-fan.org
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, p...@city-fan.org,
perl-devel@lists.fedoraproject.org
   External Bug ID: CPAN 125832



perl-DateTime-Format-Builder-0.8100 package delivers Tutorial.pod, MySQL.pm,
and W3CDTF.pm files whose license declaration is:


Copyright (c) 2003 Kellan Elliott-McCrea.  All rights reserved.  This program
is free software; you can redistribute it and/or modify it under the
same terms as Perl itself.

The full text of the license can be found in the LICENSE file included
with this module.


That means they are "GPL+ or Artistic", but package license tag is "Artistic
2.0". Please change the license tag to "Artistic 2.0 and (GPL+ or Artistic)".

I also reported the discrepancy between the declaration and LICENSE content to
the upstream .

All Fedoras are affected.

-- 
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/message/ZY3UU7DFUCFSOUXYAIHZH3B4HM2EIYZB/

glassfish-el-javadoc license change

[Mikolaj Izdebski]

License of glassfish-el-javadoc package was changed
from: CDDL-1.1 or GPLv2 with exceptions
to: (CDDL or GPLv2 with exceptions) and ASL 2.0

https://src.fedoraproject.org/rpms/glassfish-el/c/a6128b12aa9e18b5adc9701fcfe36d68b3c764b8

-- 
Mikolaj Izdebski
Senior Software Engineer, Red Hat
IRC: mizdebsk
___
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/message/3BJNIVRVJ6WXFD3EASE4PULE5DIHTH3W/

Fedora Rawhide-20180711.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 19/138 (x86_64), 23/24 (i386), 1/2 (arm)

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

ID: 256995  Test: x86_64 Server-dvd-iso server_firewall_default
URL: https://openqa.fedoraproject.org/tests/256995
ID: 256998  Test: x86_64 Server-dvd-iso server_role_deploy_database_server
URL: https://openqa.fedoraproject.org/tests/256998
ID: 257000  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/257000
ID: 257055  Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/257055
ID: 257070  Test: x86_64 universal install_shrink_ntfs
URL: https://openqa.fedoraproject.org/tests/257070
ID: 257074  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/257074
ID: 257079  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/257079
ID: 257092  Test: x86_64 universal install_multi_empty@uefi
URL: https://openqa.fedoraproject.org/tests/257092
ID: 257101  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/257101
ID: 257110  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/257110
ID: 257111  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/257111
ID: 257113  Test: x86_64 universal install_delete_partial
URL: https://openqa.fedoraproject.org/tests/257113
ID: 257123  Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/257123
ID: 257124  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/257124
ID: 257128  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/257128
ID: 257132  Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/257132
ID: 257136  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/257136

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

ID: 256999  Test: x86_64 Server-dvd-iso server_cockpit_default
URL: https://openqa.fedoraproject.org/tests/256999
ID: 257013  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/257013
ID: 257014  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/257014
ID: 257017  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/257017
ID: 257034  Test: i386 Workstation-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/257034
ID: 257035  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/257035
ID: 257036  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/257036
ID: 257050  Test: i386 KDE-live-iso install_default
URL: https://openqa.fedoraproject.org/tests/257050
ID: 257051  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/257051
ID: 257080  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/257080
ID: 257137  Test: i386 universal install_package_set_kde
URL: https://openqa.fedoraproject.org/tests/257137
ID: 257139  Test: i386 universal upgrade_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/257139
ID: 257140  Test: i386 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/257140
ID: 257141  Test: i386 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/257141
ID: 257142  Test: i386 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/257142
ID: 257143  Test: i386 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/257143
ID: 257144  Test: i386 universal install_blivet_btrfs
URL: https://openqa.fedoraproject.org/tests/257144
ID: 257145  Test: i386 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/257145
ID: 257146  Test: i386 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/257146
ID: 257147  Test: i386 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/257147
ID: 257148  Test: i386 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/257148
ID: 257149  Test: i386 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/257149
ID: 257150  Test: i386 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/257150
ID: 257151  Test: i386 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/257151
ID: 257152  Test: i386 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/257152
ID: 257153  Test: i386 

Re: [HEADS UP] Removal of GCC from the buildroot

[Simo Sorce]

On Thu, 2018-07-12 at 07:32 +, Petr Pisar wrote:
> On 2018-07-11, Zbigniew Jędrzejewski-Szmek  wrote:
> > The effects of fsync are impossible to see unless you hard-reboot
> > the
> > machine.
> 
> Are you sure non-fsynced changes are are guaranteed to be visible on
> block cache level? E.g. if you mix read/write and mmaped I/O from
> different processes?

In linux file writes and memory writes all hit the unified page cache
so there is not difference at all, only direct io skips the page cache
IIRC (but it should also invalidate it, so again no issues to
applications).

fsync only really make sure that what's in memory is pushed down to
disk and is safely on permanent storage (which is a lie with some
storage, but that is a different problem).

> > I wonder if it wouldn't be more robust to use nspawn's syscall
> > filter to filter the fsync calls.
> 
> Can the syscall filter fake a success of the syscall return value?
> Correctly written applications check fsync() return value and forward
> the error.

No, nspawn's filter just uses seccmop filters, which return
EINVAL/EPERM (IIRC) on blocked arguments/syscalls

So it is indeed not appropriate to use nspawn's filters to block
fsync()

Simo.
___
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/message/JPE57JTKSNDEC7BZ6HBSITJVWGBXDCY4/

Re: Packages which use the BuildRoot: directive

[Kevin Kofler]

Simo Sorce wrote:
> Isn't tooling in our dist-git commit hooks or push hooks that simply
> reject commits that remove changelogs or re-add unwanted sections the
> way to go here ?

Removing changelog entries is necessary to bring diverged branches back into 
sync. I always destroy the branch changelog in favor of the Rawhide one if I 
sync a new version from Rawhide to the branch. (Then I merge both ways, so 
that the branches become fast-forwardable again.)

Kevin Kofler
___
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/message/RZKLF7KRNPX3C4WEHMUQSLWTKN534CXQ/

Re: [HEADS UP] Removal of GCC from the buildroot

[Zbigniew Jędrzejewski-Szmek]

On Thu, Jul 12, 2018 at 07:32:19AM +, Petr Pisar wrote:
> On 2018-07-11, Zbigniew Jędrzejewski-Szmek  wrote:
> > The effects of fsync are impossible to see unless you hard-reboot the
> > machine.
> 
> Are you sure non-fsynced changes are are guaranteed to be visible on
> block cache level? E.g. if you mix read/write and mmaped I/O from
> different processes?

Block cache — no, I don't think so. But do we have packages that do
anything like this during build? It'd require low-level fs support
and would be probably pretty fragile anyway.

> > I wonder if it wouldn't be more robust to use nspawn's syscall filter
> > to filter the fsync calls.
> 
> Can the syscall filter fake a success of the syscall return value?
> Correctly written applications check fsync() return value and forward
> the error.

It can, e.g. something like system-nspawn --system-call-filter='~sync:0 fsync:0'
should be a good start.

Zbyszek
___
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/message/XPYRD7LMNLJGXCYUF5HTSJZIP6P5VOOV/

Re: Packages which use the BuildRoot: directive

[Simo Sorce]

On Wed, 2018-07-11 at 12:16 -0400, Josh Boyer wrote:
> On Wed, Jul 11, 2018 at 11:58 AM Igor Gnatenko
>  wrote:
> > 
> > On Wed, Jul 11, 2018 at 5:02 PM Josh Boyer  > rg> wrote:
> > > 
> > > On Wed, Jul 11, 2018 at 10:40 AM Jason L Tibbitts III  > > .uh.edu> wrote:
> > > > 
> > > > > > > > > "JB" == Josh Boyer 
> > > > > > > > > writes:
> > > > 
> > > > JB> That's impossible to enforce and unrealistic.
> > > > 
> > > > I will go as far as "it's somewhat difficult to enforce and
> > > > idealistic",
> > > > but no further.
> > > > 
> > > > JB> We can say that as much as we'd like, but there is nothing
> > > > we can do
> > > > JB> to prevent people from syncing from elsewhere.
> > > > 
> > > > There are lots of things we can't completely prevent, but that
> > > > doesn't
> > > > mean we shouldn't have rules against them.
> > > 
> > > OK.  I'll go further and say it's actively antagonistic to people
> > > that
> > > want to maintain spec files in a common location across a variety
> > > of
> > > distributions.  It seems more reasonable to have a guideline that
> > > requires people to put a comment in the spec file if it is
> > > maintained
> > > outside of Fedora and point to the proper location to file issues
> > > against.  That doesn't prevent people in the Fedora project from
> > > making changes in dist-git and it'd certainly be way more helpful
> > > in
> > > the long run to get the issue corrected upstream so we don't keep
> > > having the same import issues over and over.
> > 
> > 
> > I will disagree with this (and I also think there was an FPC ticket
> > about this).
> > Do you expect automated tooling to go to upstream and file PRs?
> > People can
> 
> I'd expect automated tooling to skip such packages based on a keyword
> or control file in dist-git.
> 
> > maintain their specs wherever they want, but they should be
> > prepared that
> > Fedora will change their specs and they should not overwrite such
> > changes.
> 
> I said that as well.  What you're missing is the part where people
> tell the actual maintainers something changed.
> 
> > > > JB> Having it in the guidelines seems to give a false sense of
> > > > security.
> > > > 
> > > > I don't understand how a guideline would ever give any "sense
> > > > of
> > > > security".  What would you expect a guideline to secure
> > > > against?
> > > > They say what you are and aren't supposed to do, and not much
> > > > more.
> > > 
> > > Yet people are surprised when they aren't followed, which is what
> > > I
> > > meant by a false sense of security.  "The guidelines say this so
> > > it
> > > must be true!", yet the guideline is unrealistic.
> > > 
> > > > It's not much different than a code of conduct.  If there's
> > > > anything
> > > > that's "impossible to enforce and unrealistic", it's that.  But
> > > > we
> > > > certainly shouldn't get rid of a "be nice to each other" rule
> > > > just
> > > > because such a rule would give someone a false sense of
> > > > security that
> > > > they can post to a mailing list without getting nasty emails
> > > > (as recent
> > > > threads on the subject of specfile cleanups have shown).
> > > 
> > > Heh, that's fair.  I think the analogy conflates two very
> > > different
> > > things though.  CoC is for human behavior norms, which are wide
> > > and
> > > varied.  Packaging guidelines tend to be more concrete, focused
> > > around
> > > technology and less open to interpretation.  They say
> > > "guidelines" but
> > > if they aren't followed people treat them as rules and require
> > > exceptions and exclusions.
> > > 
> > > > And certainly we can work to enforce this particular
> > > > rule.  It's not
> > > > hard to watch for commits which delete, say, the mass rebuild
> > > > changelog
> > > > entries or reintroduce one of these recently removed tags and
> > > > then alert
> > > > someone when necessary.  That work is already in
> > > > progress.  It's would
> > > > technically be even easier to do that check in a git hook and
> > > > simply
> > > > refuse to accept the push, if we really wanted to go that far.
> > > 
> > > I know you said this for argumentation's sake, but you're just
> > > proving
> > > my two points above.  All of that makes participating in Fedora
> > > harder, for little benefit outside of sticking to a guideline
> > > that
> > > doesn't make sense.  You and I are going to likely disagree on
> > > this
> > > point, and that's OK.
> > > 
> > > And I think the mass rebuild changelogs are unnecessary and
> > > convey no
> > > valuable information, so *shrug*.
> > 
> > 
> > It's not only changelogs, people keep re-adding BuildRoot and
> > %clean section.
> > People keep overriding changes we've done in Fedora when they
> > import from
> > "upstream".
> 
> Because nobody is communicating with upstream and fixing it
> there.  In
> some cases it'll be met with a shrug (like changelogs).  In many, it
> might actually result in upstream making a similar fix.

Isn't tooling in our 

Re: Haskell failures: relocation refers to local symbol "" [1], which is defined in a discarded section

[Florian Weimer]

On 07/12/2018 02:04 AM, Elliott Sales de Andrade wrote:

Does anyone know what's going on here? Is is annobin, new binutils, something 
else? The earliest failing build I can find is git-annex [3], and the 
dependency changes show annobin, binutils, and glibc (among others.)


It's a change in the glibc startup code, which triggers something which 
looks like a bug in the gold linker.  I filed a non-Haskell reproducer here:


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

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/message/MRHJWZO7KT5TEFUEHQNMXAR3ULLPDDZJ/

Re: F29 Self Contained Change: Deprecate YUM 3

[Tom Hughes]

On 12/07/18 09:15, Daniel Mach wrote:

On Thu, Jul 5, 2018 at 9:45 PM, Kevin Fenzi > wrote:


koji is kinda important. I think this is meaning python2-koji?
I would hope python3-koji/koji stays around?

ditto


I believe koji is only in the list because it has a require
on createrepo which (a) it doesn't really need as it can be
configured to use createrepo_c instead and (b) won't be a
problem once createrepo_c provides createrepo which I thought
was supposed to be happening?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://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/message/AN2ZQYQN6PKCKORU2JT7M4EUKLDBTNTR/

Re: F29 Self Contained Change: Deprecate YUM 3

[Daniel Mach]

On Thu, Jul 5, 2018 at 9:45 PM, Kevin Fenzi  wrote:

> On 06/27/2018 03:18 AM, Lubomír Sedlář wrote:
> > Removing Yyum would mean that there will no longer be /usr/bin/pungi
> > available in Fedora. This is not a problem for any work done by release
> > engineering, but it is still used by people creating spins.
> >
> > So this is a call to action: if anyone wants to continue using it, now
> > is the time to come up and port it to DNF (and Python 3).
>
> Sorry for my delay in replying here... been busy. ;(
>
> Looking at the list of things that would go away (from the wiki page):
>
> cobbler
> ddiskit
> diskimage-builder
> dlrn
> dnf-plugins-core
>
> ? dnf-plugins-core is kind of important, is this a false positive?
> Or does it mean python2-dnf-plugin*?
>
Yes, it's python2-dnf-plugin-migrate.
The list I provided contains packages from koji/dist-git/bugzilla
perspective (srpm names).

>
> fusioninventory-agent
> grinder
> imgbased
> kiwi
> koji
>
> koji is kinda important. I think this is meaning python2-koji?
> I would hope python3-koji/koji stays around?
>
ditto

>
> koji-containerbuild
>
> We like containers these days, don't we?
>
> libtaskotron
>
> And testing?
>
> lpf
> mach
> mash
> mirrormanager
>
> And mirrors (this one isn't as important as we run mirrormanager on
> rhel, but still)
>
> nagios-plugins-check-updates
> osc
> perl-Fedora-Rebuild
> plague
> pulp-rpm
> repo_manager
> repoview
> retrace-server
>
> This also runs on rhel, but sooner or later will need porting.
>
> rpm-ostree-toolbox
> sigul
>
> This is kinda important.
>
> snake
> system-config-kickstart
> yum-axelget
> yum-rhn-plugin
> yum-updatesd
>
> So, I'm personally not too keen on this at this point. I suppose if it
> happens then we will need to maintain/keep a fork of yum3 in
> infrastructure for tools, at which point it might be best to just keep
> it in the distro.
>
> I don't know the porting plans for all the above stuff, but I would
> personally really prefer retiring only after they were ported or at
> least we know there's a plan for them.
>
> If the critical packages don't get ported in time, we can postpone
removing yum to the next release.
I think the hard deadline is when Python 2 gets removed from the distro
(depending on Python 2 indicates
that some packages are not Python 3 ready yet).


> kevin
>
>
> ___
> 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/message/4ANJI5BPX2RYPNXNGJKGHQCXIYRUKIKS/
>
>
___
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/message/4Z7BY6GDP4BN4V5NRUPXD5FOGUVWYY5U/

Re: [HEADS UP] Removal of GCC from the buildroot

[Petr Pisar]

On 2018-07-11, Zbigniew Jędrzejewski-Szmek  wrote:
> The effects of fsync are impossible to see unless you hard-reboot the
> machine.

Are you sure non-fsynced changes are are guaranteed to be visible on
block cache level? E.g. if you mix read/write and mmaped I/O from
different processes?

> I wonder if it wouldn't be more robust to use nspawn's syscall filter
> to filter the fsync calls.

Can the syscall filter fake a success of the syscall return value?
Correctly written applications check fsync() return value and forward
the error.

-- Petr
___
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/message/UHF75E2SAMZEYFEMHHH265HRRXFPG4PV/

Re: Haskell failures: relocation refers to local symbol "" [1], which is defined in a discarded section

[Matt Milosevic]

On Thu, Jul 12, 2018, 02:05 Elliott Sales de Andrade <
quantum.anal...@gmail.com> wrote:

>
> Does anyone know what's going on here? Is is annobin, new binutils,
> something else? The earliest failing build I can find is git-annex [3], and
> the dependency changes show annobin, binutils, and glibc (among others.)
>

Annobin has been causing numerous issues with other packages recently, so
it is very likely this is another 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/message/5BYZFD4KAFXYY2ALD4A65VHUHFJ3TZBD/

[Bug 1600305] perl-File-Temp-0.2308 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-File-Temp-0.230.800-1.
   ||fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-07-12 02:37:23



--- Comment #1 from Petr Pisar  ---
This release changes exclusive locking to non-default and hides File::Temp::Dir
module. Suitable for Rawhide only.

-- 
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/message/WBUPQCERLHGRY2H4GYMNEOAHMVNE7M25/