Re: Release fedpkg-1.33

[Chenxiong Qi]

On Thu, 2018-05-17 at 13:42 +0800, Chenxiong Qi wrote:
> Hi all,
> 
> A new version fedpkg-1.33 is released.
> 
> Changelog
> 
> - Allow running tests against specified rpkg (cqi)
> - Fix test due to rpkg uses getpass.getuser (cqi)
> - Getting bodhi version works with Python 3 - #213 (cqi)
> - Detect Bodhi client by major version - #204 (cqi)
> - Allow requesting modular repositories without bug ID - #197
> (rdossant)
> - Fix test test_verify_sls_invalid_date - #209 (cqi)
> - Copy pip-pycurl to ensure pycurl is installed correctly (cqi)
> - Fix unicode issue for update command in Python 3 - #206 (cqi)
> - Fix a few E722 code styles errors (cqi)
> - Fix fake PDC URL in test (cqi)
> - Use tox to run tests with multiple Python versions (cqi)
> - Reword error message for missing pagure token - #194 (cqi)
> - Tell which token ACL is required for request-repo - #195 (cqi)
> - Rename incorrect references of Koshei to be Anitya (mprahl)

fedpkg has been compatible with Python 3, and defaults to Python 3 in
rawhide. Thanks Miro Hrončok for your patch to build Python 3 package.

> 
> Updates: https://bodhi.fedoraproject.org/updates/?builds=fedpkg-1.33-
> 1.
> fc27=fedpkg-1.33-1.fc28=fedpkg-1.33-
> 1.el6=fedpkg-
> 1.33-1.el7
> 

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

Schedule for Thursday's FPC Meeting (2018-05-17 16:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2018-05-17 16:00 UTC in #fedora-meeting-1 on
irc.freenode.net.

 Local time information (via. uitime):

= Day: Thursday ==
2018-05-17 09:00 PDT  US/Pacific
2018-05-17 12:00 EDT  --> US/Eastern <--
2018-05-17 16:00 UTC  UTC   
2018-05-17 17:00 BST  Europe/London 
2018-05-17 18:00 CEST Europe/Berlin 
2018-05-17 18:00 CEST Europe/Paris  
2018-05-17 21:30 IST  Asia/Calcutta 
 New Day: Friday -
2018-05-18 00:00 HKT  Asia/Hong_Kong
2018-05-18 00:00 +08  Asia/Singapore
2018-05-18 01:00 JST  Asia/Tokyo
2018-05-18 02:00 AEST Australia/Brisbane

 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open=meeting

= Followups =

#topic #657 Keeping packager tooling in sync with our guidelines 
.fpc 657
https://pagure.io/packaging-committee/issue/657

#topic #691 noarch *sub*packages with arch-specific dependencies
.fpc 691
https://pagure.io/packaging-committee/issue/691

#topic #693 Wiki:Packaging:RPMMacros
.fpc 693
https://pagure.io/packaging-committee/issue/693

#topic #714 let's kill file deps!
.fpc 714
https://pagure.io/packaging-committee/issue/714

#topic #719 Simplify packaging of forge-hosted projects 
.fpc 719
https://pagure.io/packaging-committee/issue/719

#topic #723 Guidelines for handling deprecated dependencies during
review
.fpc 723
https://pagure.io/packaging-committee/issue/723

#topic #726 Review for SELinux Independent Policy packaging Draft   
.fpc 726
https://pagure.io/packaging-committee/issue/726

#topic #743 Add link to C/C++ build flag docs. in redhat-rpm-config
.fpc 743
https://pagure.io/packaging-committee/issue/743

#topic #754 Should py3-foo obsolete py2-foo (when py2-foo is removed)?
.fpc 754
https://pagure.io/packaging-committee/issue/754

= New business =

#topic #767 Clarity for packaging addons for non-fedora applications 
.fpc 767
https://pagure.io/packaging-committee/issue/767

= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open=meeting

 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://pagure.io/packaging-committee ,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Release fedpkg-1.33

[Chenxiong Qi]

Hi all,

A new version fedpkg-1.33 is released.

Changelog

- Allow running tests against specified rpkg (cqi)
- Fix test due to rpkg uses getpass.getuser (cqi)
- Getting bodhi version works with Python 3 - #213 (cqi)
- Detect Bodhi client by major version - #204 (cqi)
- Allow requesting modular repositories without bug ID - #197
(rdossant)
- Fix test test_verify_sls_invalid_date - #209 (cqi)
- Copy pip-pycurl to ensure pycurl is installed correctly (cqi)
- Fix unicode issue for update command in Python 3 - #206 (cqi)
- Fix a few E722 code styles errors (cqi)
- Fix fake PDC URL in test (cqi)
- Use tox to run tests with multiple Python versions (cqi)
- Reword error message for missing pagure token - #194 (cqi)
- Tell which token ACL is required for request-repo - #195 (cqi)
- Rename incorrect references of Koshei to be Anitya (mprahl)

Updates: https://bodhi.fedoraproject.org/updates/?builds=fedpkg-1.33-1.
fc27=fedpkg-1.33-1.fc28=fedpkg-1.33-1.el6=fedpkg-
1.33-1.el7

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

Fedora Rawhide-20180516.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 22/137 (x86_64), 10/24 (i386), 1/2 (arm)

New failures (same test did not fail in Rawhide-20180515.n.2):

ID: 237853  Test: x86_64 Server-dvd-iso server_role_deploy_domain_controller
URL: https://openqa.fedoraproject.org/tests/237853
ID: 237866  Test: i386 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/237866
ID: 237870  Test: i386 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/237870
ID: 237872  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/237872
ID: 237877  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/237877
ID: 237962  Test: x86_64 universal install_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/237962
ID: 237969  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/237969
ID: 237974  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/237974
ID: 237977  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/237977

Old failures (same test failed in Rawhide-20180515.n.2):

ID: 237881  Test: x86_64 Workstation-live-iso base_services_start
URL: https://openqa.fedoraproject.org/tests/237881
ID: 237888  Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/237888
ID: 237889  Test: i386 Workstation-boot-iso memory_check
URL: https://openqa.fedoraproject.org/tests/237889
ID: 237904  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/237904
ID: 237915  Test: x86_64 AtomicWorkstation-dvd_ostree-iso 
base_services_start
URL: https://openqa.fedoraproject.org/tests/237915
ID: 237942  Test: x86_64 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/237942
ID: 237943  Test: x86_64 universal install_blivet_btrfs
URL: https://openqa.fedoraproject.org/tests/237943
ID: 237944  Test: x86_64 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/237944
ID: 237945  Test: x86_64 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/237945
ID: 237946  Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/237946
ID: 237947  Test: x86_64 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/237947
ID: 237948  Test: x86_64 universal install_blivet_ext3@uefi
URL: https://openqa.fedoraproject.org/tests/237948
ID: 237949  Test: x86_64 universal install_blivet_btrfs@uefi
URL: https://openqa.fedoraproject.org/tests/237949
ID: 237950  Test: x86_64 universal install_blivet_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/237950
ID: 237951  Test: x86_64 universal install_blivet_xfs@uefi
URL: https://openqa.fedoraproject.org/tests/237951
ID: 237952  Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/237952
ID: 237953  Test: x86_64 universal install_blivet_lvmthin@uefi
URL: https://openqa.fedoraproject.org/tests/237953
ID: 237987  Test: x86_64 universal install_rescue_encrypted
URL: https://openqa.fedoraproject.org/tests/237987
ID: 237992  Test: i386 universal install_blivet_lvmthin
URL: https://openqa.fedoraproject.org/tests/237992
ID: 237993  Test: i386 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/237993
ID: 237994  Test: i386 universal install_blivet_xfs
URL: https://openqa.fedoraproject.org/tests/237994
ID: 237995  Test: i386 universal install_blivet_no_swap
URL: https://openqa.fedoraproject.org/tests/237995
ID: 237996  Test: i386 universal install_blivet_btrfs
URL: https://openqa.fedoraproject.org/tests/237996
ID: 237997  Test: i386 universal install_blivet_ext3
URL: https://openqa.fedoraproject.org/tests/237997

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

Old soft failures (same test soft failed in Rawhide-20180515.n.2):

ID: 237867  Test: i386 Server-dvd-iso install_default
URL: https://openqa.fedoraproject.org/tests/237867
ID: 237983  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/237983

Passed openQA tests: 110/137 (x86_64), 13/24 (i386)

New passes (same test did not pass in Rawhide-20180515.n.2):

ID: 237868  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/237868
ID: 237891  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/237891
ID: 237892  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/237892
ID: 237893  Test: x86_64 KDE-live-iso 

[EPEL-devel] Re: wine 3 package

[Rex Dieter]

Ken Taylor wrote:

> I installed the wine 3 package from epel-testing this morning  on a
> newly installed CentOS 7.5 machine. The installation seemed to go fine.
> If I may ask two questions...
> 
> Does this version of wine support 32 bit Windows programs on CentOS 7.5?

No.  rhel7 (and epel7 by extension) does not support i686 arch, which is 
required for win32 support

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

Need Sponsor: PrestoPalette

[Darryl T. Agostinelli]

Hi All,
I wanted to re-introduce myself as well as ask for a sponsor for my package 
PrestoPalette.  

Here's the link to the (approved) review request:
https://bugzilla.redhat.com/show_bug.cgi?id=1570047

My original introduction email can be found here:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/X57D5ZGVACRKZ3RHHRJYUQW4FO56JG5J/

PrestoPalette is a new package that I'm trying to publish into the package repo 
and become its maintainer. 

I'm asking for a sponsor so that I can publish PrestoPalette.

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

[EPEL-devel] wine 3 package

[Ken Taylor]

I installed the wine 3 package from epel-testing this morning  on a 
newly installed CentOS 7.5 machine. The installation seemed to go fine. 
If I may ask two questions...


Does this version of wine support 32 bit Windows programs on CentOS 7.5?

If so, would someone please be kind enough to point me to some 
instructions as to how to configure the 32 bit environment?  I have 
tried configuring it as I would on Ubuntu but without luck.


Thanks,

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

soname change - libqalculate.so.17

[Mukundan Ragavan]

libqalculate soname bump is happening with v2.5.0. The following
packages are affected -

plasma-workspace
step
cantor
qalculate-kde

I will rebuild these packages.

Mukundan.



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

[Bug 1579091] New: perl-AnyEvent-Handle-UDP-0.049 is available

[bugzilla]

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

Bug ID: 1579091
   Summary: perl-AnyEvent-Handle-UDP-0.049 is available
   Product: Fedora
   Version: rawhide
 Component: perl-AnyEvent-Handle-UDP
  Keywords: FutureFeature, Triaged
  Assignee: dd...@cpan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: dd...@cpan.org, perl-devel@lists.fedoraproject.org



Latest upstream release: 0.049
Current version/release in rawhide: 0.048-5.fc28
URL: http://search.cpan.org/dist/AnyEvent-Handle-UDP/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: What services / tools still require NIS domain?

[Ian Kent]

On 16/05/18 23:17, David Kaspar [Dee'Kej] wrote:
> On Wed, May 16, 2018 at 5:07 PM, Stephen Gallagher  > wrote:
> 
> I don't think SSSD or FreeIPA *require* it. They offer netgroup 
> functionality that can be used with it. Maybe I misunderstood your question? 
> Are you just asking which things in the distro interact with NIS domains at 
> all?
> 
> Perhaps it would be better if you explained the rationale for the 
> question. For example, are you trying to figure out if we can remove all of 
> NIS from the distro?
> 
> 
> ​Sorry, I don't know much about NIS. I was coming out from what I've been 
> told.

I think you'll find NIS is still quite widely used.

NIS Plus was an attempt to improve NIS but (AFAIK) it never became widely used.
LDAP is another attempt to provide much of the table information provided by NIS
but it is far more complicated to administer.

NIS remains the simplest and easiest way to centrally manage (key, value) stores
such as password, group, netgroup, hosts etc. so it has endured.

Automount maps are another (key, value) store that can be centrally managed by
NIS and there are still a surprising number of autofs users that continue to
use it.

> 
> I'm trying to figure out, which application / tool / service still actually 
> need the fedora-domainname.service to be present in Fedora in order to 
> function correctly?

The question is kind-off ambiguous.

It's not so much applications that need the service but rather services
that can utilize the (key, value) information stored in NIS tables for the
functionality they provide that need the NIS domain to be set.

For example autofs can use NIS as an automount map source but it doesn't
depend on NIS, it can also use automount maps stored in files, LDAP, sss
etc.
 
Ian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [systemd-devel] Running “telinit u” on glibc update

[Lennart Poettering]

On Mi, 16.05.18 15:01, Florian Weimer (fwei...@redhat.com) wrote:

> In Fedora, for historic reasons, we run “/sbin/telinit u” after installing a
> new glibc RPM package version.
> 
> Does this still make sense?  Should we remove the code which invokes telinit
> from the glibc package?

So I am pretty sure this is about not keeping the old .so images maps
pinned for good, i.e. so that they can be removed from disk and don't
keep the file system busy. This isn't really necessary in systemd
though, as we will always execve() from PID1 into a new process during
shutdown, which should drop all pinned pages anyway, unconditionally
and always.

Hence, no I don't think this needs to be there. I mean, I would see
value if we could unpin the old mapped .so images system-wide,
comprehensively, right away, but such a concept doesn't exist, we only
can can do this for some services, and it's racy and hence nothing we
should attempt. Doing this just for PID 1 hence doesn't really help
much, it's a drop of water on a hot stone.

Hence, please go aahead and drop it from the rpm scripts.

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Blue Sky Discussion: EPEL-next or EPIC

[Neal Gompa]

On Wed, May 16, 2018 at 1:20 PM Matthew Miller 
wrote:

> On Tue, May 15, 2018 at 09:31:07PM -0400, Neal Gompa wrote:
> > I currently provide an EPEL-safe version of DNF in my COPR[1] that I'm
> > considering putting into EPEL, but it doesn't have the modularity stuff
> > because it's too much of a mess right now.
> > [1]: https://copr.fedorainfracloud.org/coprs/ngompa/dnf2-el7/

> Have you seen this?
> https://blog.centos.org/2018/04/yum4-dnf-for-centos-7-updates/


I did. The problem with that version is that some people can't test it
because it replaces system `rpm` and `gpgme` packages, among other things.
My version is designed to be able to ship in EPEL per the existing policy,
which allows a wider array of people to try it out.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Fop fonts issue in a freshly updated Fedora 28+

[Michele Baldessari]

Hi Peter,

On Tue, May 15, 2018 at 07:05:07PM +0200, Peter Lemenkov wrote:
> Hello All!
> 
> Just got a strange issue while generating doc-files from sources with fop:
> 
> https://kojipkgs.fedoraproject.org//work/tasks/763/26980763/build.log
> 
> Exception in thread "main" java.lang.NoSuchMethodError:
> org.apache.fontbox.cff.CFFFont.getProperty(Ljava/lang/String;)Ljava/lang/Object;
> at org.apache.fop.fonts.truetype.OTFFile.readName(OTFFile.java:134)
> at org.apache.fop.fonts.truetype.OpenFont.readFont(OpenFont.java:740)
> at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:109)
> at org.apache.fop.fonts.truetype.OFFontLoader.read(OFFontLoader.java:93)
> at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:124)
> at org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:108)
> at 
> org.apache.fop.fonts.autodetect.FontInfoFinder.find(FontInfoFinder.java:254)
> at org.apache.fop.fonts.FontAdder.add(FontAdder.java:63)
> at 
> org.apache.fop.fonts.FontDetectorFactory$DefaultFontDetector.detect(FontDetectorFactory.java:105)
> at org.apache.fop.fonts.FontManager.autoDetectFonts(FontManager.java:229)
> at 
> org.apache.fop.fonts.DefaultFontConfigurator.configure(DefaultFontConfigurator.java:82)
> at 
> org.apache.fop.render.PrintRendererConfigurator.getCustomFontCollection(PrintRendererConfigurator.java:147)
> at 
> org.apache.fop.render.PrintRendererConfigurator.setupFontInfo(PrintRendererConfigurator.java:127)
> at org.apache.fop.render.intermediate.IFUtil.setupFonts(IFUtil.java:170)
> at 
> org.apache.fop.render.intermediate.IFRenderer.setupFontInfo(IFRenderer.java:187)
> at org.apache.fop.area.RenderPagesModel.(RenderPagesModel.java:75)
> at org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:135)
> at org.apache.fop.area.AreaTreeHandler.(AreaTreeHandler.java:105)
> at 
> org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:350)
> at org.apache.fop.fo.FOTreeBuilder.(FOTreeBuilder.java:107)
> at org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:104)
> at org.apache.fop.apps.Fop.(Fop.java:78)
> at org.apache.fop.apps.FOUserAgent.newFop(FOUserAgent.java:179)
> at org.apache.fop.cli.InputHandler.renderTo(InputHandler.java:107)
> at org.apache.fop.cli.Main.startFOP(Main.java:186)
> at org.apache.fop.cli.Main.main(Main.java:216)
> make[3]: Leaving directory
> '/builddir/build/BUILD/otp-OTP-20.3.6/lib/stdlib/doc/src'
> make[3]: *** 
> [/builddir/build/BUILD/otp-OTP-20.3.6/make/x86_64-redhat-linux-gnu/otp.mk:329:
> ../pdf/stdlib-3.4.5.pdf] Error 1
> make[2]: Leaving directory '/builddir/build/BUILD/otp-OTP-20.3.6/lib/stdlib'
> make[2]: *** [/builddir/build/BUILD/otp-OTP-20.3.6/make/otp_subdir.mk:29:
> docs] Error 2
> make[1]: Leaving directory '/builddir/build/BUILD/otp-OTP-20.3.6/lib'
> make[1]: *** [/builddir/build/BUILD/otp-OTP-20.3.6/make/otp_subdir.mk:29:
> docs] Error 2
> make: *** [Makefile:416: docs] Error 2
> 
> For me it looks very much the same as the issue described here -
> https://stackoverflow.com/questions/41501641/fop-giving-nosuchmethoderror-when-font-auto-detect-enable
> 
> However I'm not sure how to fix it?

Eck and I spent some time looking at this.
So the issue is actually this one here:
-fontbox.noarch 1.8.13-4.fc28
+fontbox.noarch 2.0.9-2.fc28

The problem is that fontbox has been upgraded to 2.0.x but support for
2.0.x has landed only in FOP 2.2:
From https://xmlgraphics.apache.org/fop/2.2/changes_2.2.html:
FOP-2562: Update to PDFBox 2

So via BZ https://bugzilla.redhat.com/show_bug.cgi?id=1298915 we should
push for an update of fop to 2.2 since pdfbox is already out and
released.

cheers,
Michele
-- 
Michele Baldessari
C2A5 9DA3 9961 4FFB E01B  D0BC DDD4 DCCB 7515 5C6D
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] please review: Ticket 49665 - Remove recently added upgrade scripts that are obsolete on master branch

[Mark Reynolds]

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

https://pagure.io/389-ds-base/pull-request/49695
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Blue Sky Discussion: EPEL-next or EPIC

[Stephen John Smoogen]

On 16 May 2018 at 13:14, Kevin Fenzi  wrote:
> There's been a ton of talk about this over the years, but thanks a lot
> to Smooge for making a more formal proposal we can look at and adjust
> and see if we can get something we actually want to do. :)
>
>
> On 05/15/2018 12:06 PM, Stephen John Smoogen wrote:
>>  EPIC Planning Document
>>  __
>>
>> History / Background
> ...snip...
>>Proposed Solution
>>
>>   EPIC will match the Enterprise Linux major/minor numbers for
>>   releases. This means that a set of packages will be built
>>   for say EL5 subrelease 11 (aka 5.11). Those packages would
>>   populate for each supported architecture a release, updates
>>   and updates-testing directory. This will allow for a set of
>>   packages to be composed when the subrelease occurs and then
>>   stay until the release is ended.
>>
>>   /pub/epic/releases/5/5.11/{x86_64,source,i386,aarch64,arm,ppc64}/
>>   /pub/epic/updates/5/5.11/{x86_64,source,i386,aarch64,arm,ppc64}/
>>   /pub/epic/updates/testing/5/5.11/{x86_64,source,i386,aarch64,arm,ppc64}/
>>
>>Once a minor release is done, the old tree will be hard linked to
>>an appropriate archive directory.
>
> When is a minor release considered done? When the next minor release is
> released?
>

I would expect it would be set by policy but dictated when the next
minor release is released. In the case of the 'last' like 5.11 we may
need to have some additional policy for say 6.20 (making this up)
where packages are put in which EOL the package in the repo.
[something like xmms-3.10.2-9eol-unmaintained.i386.rpm] it would
basically be a rebuild of the last package in the repo with some
blanket file saying "This package is no longer maintained by the EPEL
project. It is recommended that you either remove this package or find
a different repository which still maintains it. You are on your own."

> ...snip
>
>>Proposed Solution
>>
>>   The main EPIC releases will be built against specific CentOS
>>   releases versus the Continual Release (CR) channel. When the
>>   next RHEL minor is announced, the EPIC releng will create
>>   new git branch from the current minor version (aka 5.10 →
>>   5.11).  Packagers can then make major updates to versions or
>>   other needs done. When the CentOS CR is populated with the
>>   new rpms, packages will be built in the new tree using those
>>   packages.  After 2 weeks, the EPIC minor release will be
>>   frozen and any new packages or fixes will occur in the
>>   updates tree.
>
> So, the branching and build against CR and freezing the release would
> all be done by epel releng, or would it be a opt-in thing by maintainers?
>

I figure it would be done by EPEL releng. I think if it were opt-in
then it would be basically be 'meh' except for that 1 person who can't
stand anyone touching their package.

> ...snip...
>
>>There are several naming patterns which need to be researched:
>>   //epic/6/10/
>>   //epic/6/11/
>>   //epic/7/6/
>>   //epic/7/7/
>>   //epic-6/6.10/
>>   //epic-6/6.11/
>>   //epic-7/7.6/
>>   //epic-7/7.7/
>>   //epic-6.10/
>>   //epic-6.11/
>>   //epic-7.6/
>>   //epic-7.7/
>>
>>Git module patterns will need to match what upstream delivers for any
>>future EL.
>
> This will of course need tooling changes if it's done in Fedora
> Infrastructure, but doable.
>
>>   Continous Integration (CI) Gating
>>
>> EPIC-6
>>
>>The EL-6 lifecycle is reaching its final sub releases with more
>>focus and growth in EL-7 and the future. Because of this gating
>>will be turned off EPIC-6. Testing of packages can be done at the
>>packagers discretion but is not required.
>>
>> EPIC-7
>>
>>The EL-7 lifecycle is midstream with 1-2 more minor releases with
>>major API changes. Due to this, it makes sense to research if
>>gating can be put in place for the next minor release. If the time
>>and energy to retrofit tools to the older EL are possible then it
>>can be turned on.
>>
>> EPIC-next
>>
>>Because gating is built into current Fedora releases, there should
>>be no problem with turning it on for a future release. Packages
>>which do not pass testing will be blocked just as they will be in
>>Fedora 29+ releases.
>
> Provided all the people doing that are ok with adding another
> target/more builds/more artifacts, etc. ie, communication would need to
> be made and acks from the various groups.
>

Agreed. From the fact that we have arbitrary branching, anyone can
make a module and a bunch of other things.. I figured adding a couple
of defined targets wasn't too much to ask.

> ...snip...
>
>>The steps for EPIC release engineering will be the following:
>>
>> 1. Branch all current packages from 

[389-devel] please review: Ticket 49689 - Move Cockpit UI plugin to subpackage of 389-ds-base

[Mark Reynolds]

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

https://pagure.io/389-ds-base/pull-request/49694
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Fedora Atomic Host Two Week Release Announcement: 28.20180515.1

[Dusty Mabe]

On 05/16/2018 02:03 PM, nore...@fedoraproject.org wrote:
> 
> A new Fedora Atomic Host update is available via an OSTree update:
> 
> Version: 28.20180515.1
> Commit(x86_64): 
> a29367c58417c28e2bd8306c1f438b934df79eba13706e078fe8564d9e0eb32b
> Commit(aarch64): 
> ec501e5a6833e6117632c3a7fc90ef17530399b6411ad9ba2c5c85f22cabe8dd
> Commit(ppc64le): 
> dfe24e5d495ec16fbe2d61e6b494def2b119301f6565b8b6ecd542d79b02df89
> 
> 
> We are releasing images from multiple architectures but please note
> that x86_64 architecture is the only one that undergoes automated
> testing at this time.
> 
> Existing systems can be upgraded in place via e.g. `atomic host upgrade`.
> 
> Corresponding image media for new installations can be downloaded from:
> 
> https://getfedora.org/en/atomic/download/
> 
> Alternatively, image artifacts can be found at the following links:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180515.1.aarch64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180515.1.aarch64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-28-20180515.1.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180515.1.ppc64le.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180515.1.ppc64le.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-28-20180515.1.iso
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/x86_64/images/Fedora-AtomicHost-28-20180515.1.x86_64.qcow2
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/x86_64/images/Fedora-AtomicHost-28-20180515.1.x86_64.raw.xz
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-28-20180515.1.x86_64.vagrant-libvirt.box
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-28-20180515.1.x86_64.vagrant-virtualbox.box
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-28-20180515.1.iso
> 
> Respective signed CHECKSUM files can be found here:
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180515.1-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/aarch64/iso/Fedora-AtomicHost-28-20180515.1-aarch64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180515.1-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/ppc64le/iso/Fedora-AtomicHost-28-20180515.1-ppc64le-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/x86_64/images/Fedora-AtomicHost-28-20180515.1-x86_64-CHECKSUM
> https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/x86_64/iso/Fedora-AtomicHost-28-20180515.1-x86_64-CHECKSUM
> 
> For direct download, the "latest" targets are always available here:
> https://getfedora.org/atomic_iso_latest
> https://getfedora.org/atomic_qcow2_latest
> https://getfedora.org/atomic_raw_latest
> https://getfedora.org/atomic_vagrant_libvirt_latest
> https://getfedora.org/atomic_vagrant_virtualbox_latest
> 
> Filename fetching URLs are available here:
> https://getfedora.org/atomic_iso_latest_filename
> https://getfedora.org/atomic_qcow2_latest_filename
> https://getfedora.org/atomic_raw_latest_filename
> https://getfedora.org/atomic_vagrant_libvirt_latest_filename
> https://getfedora.org/atomic_vagrant_virtualbox_latest_filename
> 
> For more information about the latest targets, please reference the Fedora
> Atomic Wiki space.
> 
> 
> https://fedoraproject.org/wiki/Atomic_WG#Fedora_Atomic_Image_Download_Links
> 
> Do note that it can take some of the mirrors up to 12 hours to "check-in" at
> their own discretion.
> 
> Thank you,
> Fedora Release Engineering
> 

This is our second release of Fedora 28 Atomic Host. This release contains
a security fix for CVE-2018-: 
https://access.redhat.com/security/cve/cve-2018-
It also contains a new kernel, systemd, ostree, selinux, podman, etc.
Note in the diff output below that buildah was removed. buildah is no
longer a dependency for `podman build` to work so the 

Fedora Atomic Host Two Week Release Announcement: 28.20180515.1

[noreply]

A new Fedora Atomic Host update is available via an OSTree update:

Version: 28.20180515.1
Commit(x86_64): a29367c58417c28e2bd8306c1f438b934df79eba13706e078fe8564d9e0eb32b
Commit(aarch64): 
ec501e5a6833e6117632c3a7fc90ef17530399b6411ad9ba2c5c85f22cabe8dd
Commit(ppc64le): 
dfe24e5d495ec16fbe2d61e6b494def2b119301f6565b8b6ecd542d79b02df89


We are releasing images from multiple architectures but please note
that x86_64 architecture is the only one that undergoes automated
testing at this time.

Existing systems can be upgraded in place via e.g. `atomic host upgrade`.

Corresponding image media for new installations can be downloaded from:

https://getfedora.org/en/atomic/download/

Alternatively, image artifacts can be found at the following links:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180515.1.aarch64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180515.1.aarch64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-28-20180515.1.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180515.1.ppc64le.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180515.1.ppc64le.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-28-20180515.1.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/x86_64/images/Fedora-AtomicHost-28-20180515.1.x86_64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/x86_64/images/Fedora-AtomicHost-28-20180515.1.x86_64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-28-20180515.1.x86_64.vagrant-libvirt.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-28-20180515.1.x86_64.vagrant-virtualbox.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-28-20180515.1.iso

Respective signed CHECKSUM files can be found here:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/aarch64/images/Fedora-AtomicHost-28-20180515.1-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/aarch64/iso/Fedora-AtomicHost-28-20180515.1-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/ppc64le/images/Fedora-AtomicHost-28-20180515.1-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/ppc64le/iso/Fedora-AtomicHost-28-20180515.1-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/x86_64/images/Fedora-AtomicHost-28-20180515.1-x86_64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-28-20180515.1/AtomicHost/x86_64/iso/Fedora-AtomicHost-28-20180515.1-x86_64-CHECKSUM

For direct download, the "latest" targets are always available here:
https://getfedora.org/atomic_iso_latest
https://getfedora.org/atomic_qcow2_latest
https://getfedora.org/atomic_raw_latest
https://getfedora.org/atomic_vagrant_libvirt_latest
https://getfedora.org/atomic_vagrant_virtualbox_latest

Filename fetching URLs are available here:
https://getfedora.org/atomic_iso_latest_filename
https://getfedora.org/atomic_qcow2_latest_filename
https://getfedora.org/atomic_raw_latest_filename
https://getfedora.org/atomic_vagrant_libvirt_latest_filename
https://getfedora.org/atomic_vagrant_virtualbox_latest_filename

For more information about the latest targets, please reference the Fedora
Atomic Wiki space.

https://fedoraproject.org/wiki/Atomic_WG#Fedora_Atomic_Image_Download_Links

Do note that it can take some of the mirrors up to 12 hours to "check-in" at
their own discretion.

Thank you,
Fedora Release Engineering
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intel's Clear Linux optimizations

[stan]

On Wed, 16 May 2018 20:39:02 +0530
Manas Mangaonkar  wrote:

> > Yes, if someone wishes to build and maintain that kernel.  
> 
> How difficult is this ? newbie, sophmore cse student but would like
> to give this a shot if this isn't too difficult.Want to start
> contributing.

I build a custom kernel from the src.rpm with a patch to random.c to add
code so that my hardware RNG is used to reseed the chacha20 PRNG on a
periodic basis.  That is similar, if easier, to what you would have to
do to maintain a different kernel.  The first time would be a bear, then
after that it would just be repeating the procedure.

I use the older rpmbuild method, so I'm not sure how that agrees with
the currently recommended method.  Here goes.  This is long, and a lot
of the details are missing.

Install the rpmbuild packages.

Run rpmbuild-setuptree to build the rpmbuild directory tree in your
home directory.

Go to koji and get the kernel src.rpm

Run rpm -ivh to install it to the rpmbuild directory.

I then use screen to have a bunch of terms available, so I'm not
constantly having to switch directories, but you could just switch
between a bunch of virtual consoles.

Go into the ~/rpmbuild/SPECS directory.  You'll see kernel.spec in
there.

Run rpmbuild -bp kernel.spec  to expand the source.

When it is done, go into the ~/rpmbuild/BUILD/kernel[]/linux[]/
directory.  Since fedora now builds all kernels from a git repository,
it is necessary to build patches for them from that git repository.
It's a PITA, but necessary.

Run git add .

Run git commit -a

Just add a throwaway comment and save.

Run git status.

Everything should be up to date.

Run git config user.name "blah"

Run git config user.email "b...@blah.com"

Run git branch clear  to create a new branch for the clear linux kernel.

Run git checkout clear  to set that as the working branch.

This is more complicated than I need, since you are basically creating
a patch from the fedora kernel to the clear kernel.  Delete everything
in the branch except the hidden .git directory.

Grab the clear linux source tree and put it into the clear branch you
just cleaned up.  tar? git pull?

Run git add .

Run git commit -a.

Put in a comment and save.

Run git status to be sure the branch is clean.

Run git format-patch clear-linux

Put the resulting patch in ~/rpmbuild/SOURCES with a unique numerical
prefix.

Put the patch name in ~/rpmbuild/SPECS/kernel.spec just before END OF
PATCHES.

Run rpmbuild -bb kernel.spec

You will have the kernel rpm files in ~/rpmbuild/RPMS/x86_64

The gotchas are left as an exercise for the reader (if you are a
newbie, there will be lots of them).  :-)  And it's rough, there is a
lot of optimization that I left out.

So it's a lot of work, but a great learning experience if you are up
for it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Blue Sky Discussion: EPEL-next or EPIC

[Matthew Miller]

On Tue, May 15, 2018 at 09:31:07PM -0400, Neal Gompa wrote:
> I currently provide an EPEL-safe version of DNF in my COPR[1] that I'm
> considering putting into EPEL, but it doesn't have the modularity stuff
> because it's too much of a mess right now.
> [1]: https://copr.fedorainfracloud.org/coprs/ngompa/dnf2-el7/

Have you seen this?
https://blog.centos.org/2018/04/yum4-dnf-for-centos-7-updates/

-- 
Matthew Miller

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

[EPEL-devel] Re: Blue Sky Discussion: EPEL-next or EPIC

[Kevin Fenzi]

There's been a ton of talk about this over the years, but thanks a lot
to Smooge for making a more formal proposal we can look at and adjust
and see if we can get something we actually want to do. :)


On 05/15/2018 12:06 PM, Stephen John Smoogen wrote:
>  EPIC Planning Document
>  __
> 
> History / Background
...snip...
>Proposed Solution
> 
>   EPIC will match the Enterprise Linux major/minor numbers for
>   releases. This means that a set of packages will be built
>   for say EL5 subrelease 11 (aka 5.11). Those packages would
>   populate for each supported architecture a release, updates
>   and updates-testing directory. This will allow for a set of
>   packages to be composed when the subrelease occurs and then
>   stay until the release is ended.
> 
>   /pub/epic/releases/5/5.11/{x86_64,source,i386,aarch64,arm,ppc64}/
>   /pub/epic/updates/5/5.11/{x86_64,source,i386,aarch64,arm,ppc64}/
>   /pub/epic/updates/testing/5/5.11/{x86_64,source,i386,aarch64,arm,ppc64}/
> 
>Once a minor release is done, the old tree will be hard linked to
>an appropriate archive directory.

When is a minor release considered done? When the next minor release is
released?

...snip

>Proposed Solution
> 
>   The main EPIC releases will be built against specific CentOS
>   releases versus the Continual Release (CR) channel. When the
>   next RHEL minor is announced, the EPIC releng will create
>   new git branch from the current minor version (aka 5.10 →
>   5.11).  Packagers can then make major updates to versions or
>   other needs done. When the CentOS CR is populated with the
>   new rpms, packages will be built in the new tree using those
>   packages.  After 2 weeks, the EPIC minor release will be
>   frozen and any new packages or fixes will occur in the
>   updates tree.

So, the branching and build against CR and freezing the release would
all be done by epel releng, or would it be a opt-in thing by maintainers?

...snip...

>There are several naming patterns which need to be researched:
>   //epic/6/10/
>   //epic/6/11/
>   //epic/7/6/
>   //epic/7/7/
>   //epic-6/6.10/
>   //epic-6/6.11/
>   //epic-7/7.6/
>   //epic-7/7.7/
>   //epic-6.10/
>   //epic-6.11/
>   //epic-7.6/
>   //epic-7.7/
> 
>Git module patterns will need to match what upstream delivers for any
>future EL.

This will of course need tooling changes if it's done in Fedora
Infrastructure, but doable.

>   Continous Integration (CI) Gating
> 
> EPIC-6
> 
>The EL-6 lifecycle is reaching its final sub releases with more
>focus and growth in EL-7 and the future. Because of this gating
>will be turned off EPIC-6. Testing of packages can be done at the
>packagers discretion but is not required.
> 
> EPIC-7
> 
>The EL-7 lifecycle is midstream with 1-2 more minor releases with
>major API changes. Due to this, it makes sense to research if
>gating can be put in place for the next minor release. If the time
>and energy to retrofit tools to the older EL are possible then it
>can be turned on.
> 
> EPIC-next
> 
>Because gating is built into current Fedora releases, there should
>be no problem with turning it on for a future release. Packages
>which do not pass testing will be blocked just as they will be in
>Fedora 29+ releases.

Provided all the people doing that are ok with adding another
target/more builds/more artifacts, etc. ie, communication would need to
be made and acks from the various groups.

...snip...

>The steps for EPIC release engineering will be the following:
> 
> 1. Branch all current packages from X.Y to X.Y+1
> 2. Make any bugzilla updates needed
> 3. Rebuild all branched packages against CR
> 4. File FTBFS against any packages.
> 5. Packagers will announce major updates to mailing list
> 6. Packagers will build updates against CR.
> 7. 2 weeks in, releng will cull any packages which are still FTBFS
> 8. 2 weeks in, releng will compose and lock the X.Y+1 release
> 9. symlinks will point to the new minor release.
>10. 4 weeks in, releng will finish archiving off the X.Y release

All very doable, but also a fair bit of work. :)

Basically this is the same process we used for major release bringup in
epel. It's basically like rawhide at first, all builds go in every day,
then things that are broken are culled, etc, then finally updates turned
on. (But in this case epic would have a seperate update repo).

> Between Releases
> 
>Updates and new packages between releases will be pushed to the
>appropriate /updates/X.Y/ tree. Packagers will be encouraged to
>only make minor non-api breaking updates during this time. Major
>changes are possible, but need to follow 

Re: Intel's Clear Linux optimizations

[Stephen John Smoogen]

On 16 May 2018 at 11:09, Manas Mangaonkar  wrote:
>> Yes, if someone wishes to build and maintain that kernel.
>
> How difficult is this ? newbie, sophmore cse student but would like to give
> this a shot if this isn't too difficult.Want to start contributing.
>
>

It is going to be one of those, you aren't going to know until you
have tried to do it. You could look at one of the 'default' kernels
src.rpms and then set up a copr to build it in with the source code
you want. You can then work out the hangs/crashes/etc from there. I
would probably start with building something smaller in COPR so you
know what a spec file does, what copr does and what it can get.


>
> On Wed, May 16, 2018 at 8:18 PM, Josh Boyer 
> wrote:
>>
>> On Tue, May 15, 2018 at 11:39 PM Hayden Barnes 
>> wrote:
>>
>> > Would it be possible to mirror the Clear Linux kernel in copr or a
>> third-party dnf repo?
>>
>> Yes, if someone wishes to build and maintain that kernel.
>>
>> josh
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
>
> --
> Regards,
> Manas Mangaonkar
> Content Manager | Intern
> ProgrammingHub
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



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

Fedora rawhide compose report: 20180516.n.0 changes

[Fedora Rawhide Report]

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

Re: Intel's Clear Linux optimizations

[Sérgio Basto]

On Wed, 2018-05-16 at 10:48 -0400, Josh Boyer wrote:
> On Tue, May 15, 2018 at 11:39 PM Hayden Barnes 
> wrote:
> 
> > Would it be possible to mirror the Clear Linux kernel in copr or a
> 
> third-party dnf repo?
> 
> Yes, if someone wishes to build and maintain that kernel.

BTW : I'd like test drm-tip kernel 

https://cgit.freedesktop.org/drm-tip?
related with https://01.org/linuxgraphics/documentation/build-guide-0

anyone ? 

reference: 
https://bugs.freedesktop.org/show_bug.cgi?id=103414#c16


> josh
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What services / tools still require NIS domain?

[Ralf Corsepius]

On 05/16/2018 05:02 PM, David Kaspar [Dee'Kej] wrote:

Hello people,

I would like to know if you know about any service / tool / application 
that still relies on NIS domain to be set in Fedora?


So far, I know only about SSSD/FreeIPA relying on it. Does anybody know 
anything else? All replies are welcome. :)


Existing user installations require it - and likely will continue to 
require it for at least another decade.


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

Re: What services / tools still require NIS domain?

[Alexander Bokovoy]

On ke, 16 touko 2018, David Kaspar [Dee'Kej] wrote:

Hello people,

I would like to know if you know about any service / tool / application
that still relies on NIS domain to be set in Fedora?

So far, I know only about SSSD/FreeIPA relying on it. Does anybody know
anything else? All replies are welcome. :)

Sudo relies on netgroups which are provided by NIS.

FreeIPA/SSSD do not require NIS, they provide NIS server side and
implement its use for sudo and legacy clients which may require it.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What services / tools still require NIS domain?

[David Kaspar [Dee'Kej]]

On Wed, May 16, 2018 at 5:07 PM, Stephen Gallagher 
wrote:

> I don't think SSSD or FreeIPA *require* it. They offer netgroup
> functionality that can be used with it. Maybe I misunderstood your
> question? Are you just asking which things in the distro interact with NIS
> domains at all?
>
> Perhaps it would be better if you explained the rationale for the
> question. For example, are you trying to figure out if we can remove all of
> NIS from the distro?
>

​Sorry, I don't know much about NIS. I was coming out from what I've been
told.

I'm trying to figure out, which application / tool / service still actually
need the fedora-domainname.service to be present in Fedora in order to
function correctly?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intel's Clear Linux optimizations

[Manas Mangaonkar]

> Yes, if someone wishes to build and maintain that kernel.

How difficult is this ? newbie, sophmore cse student but would like to give
this a shot if this isn't too difficult.Want to start contributing.



On Wed, May 16, 2018 at 8:18 PM, Josh Boyer 
wrote:

> On Tue, May 15, 2018 at 11:39 PM Hayden Barnes 
> wrote:
>
> > Would it be possible to mirror the Clear Linux kernel in copr or a
> third-party dnf repo?
>
> Yes, if someone wishes to build and maintain that kernel.
>
> josh
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



-- 
Regards,
Manas Mangaonkar
Content Manager | Intern
ProgrammingHub 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What services / tools still require NIS domain?

[Stephen Gallagher]

On Wed, May 16, 2018 at 11:03 AM David Kaspar [Dee'Kej] 
wrote:

> Hello people,
>
> I would like to know if you know about any service / tool / application
> that still relies on NIS domain to be set in Fedora?
>
> So far, I know only about SSSD/FreeIPA relying on it. Does anybody know
> anything else? All replies are welcome. :)
>
>

I don't think SSSD or FreeIPA *require* it. They offer netgroup
functionality that can be used with it. Maybe I misunderstood your
question? Are you just asking which things in the distro interact with NIS
domains at all?

Perhaps it would be better if you explained the rationale for the question.
For example, are you trying to figure out if we can remove all of NIS from
the distro?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

What services / tools still require NIS domain?

[David Kaspar [Dee'Kej]]

Hello people,

I would like to know if you know about any service / tool / application
that still relies on NIS domain to be set in Fedora?

So far, I know only about SSSD/FreeIPA relying on it. Does anybody know
anything else? All replies are welcome. :)

Best regards,

David Kaspar [Dee'Kej]
*Associate Software Engineer*
*Brno, Czech Republic*

RED HAT | TRIED. TESTED. TRUSTED.
Every airline in the Fortune 500 relies on Red Hat.
Find out why at Trusted | Red Hat .
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Test-Announce] Fedora 29 Rawhide 20180516.n.0 nightly compose nominated for testing

[rawhide]

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

Notable package version changes:
pykickstart - 20180513.n.1: pykickstart-3.13-1.fc29.src, 20180516.n.0: 
pykickstart-3.14-1.fc29.src
lorax - 20180513.n.1: lorax-29.2-1.fc29.src, 20180516.n.0: lorax-29.3-1.fc29.src

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

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

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

The individual test result pages are:

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

Thank you for testing!
-- 
Mail generated by relvalconsumer: https://pagure.io/fedora-qa/relvalconsumer
___
test-announce mailing list -- test-annou...@lists.fedoraproject.org
To unsubscribe send an email to test-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intel's Clear Linux optimizations

[Josh Boyer]

On Tue, May 15, 2018 at 11:39 PM Hayden Barnes  wrote:

> Would it be possible to mirror the Clear Linux kernel in copr or a
third-party dnf repo?

Yes, if someone wishes to build and maintain that kernel.

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

[Bug 1578812] perl-Moose-2.2011 is available

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Moose-2.2011-1.fc29
 Resolution|--- |RAWHIDE
   Assignee|emman...@seyman.fr  |p...@city-fan.org
Last Closed||2018-05-16 10:45:58



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

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

[rpms/perl-Moose] New Commits To "rpms/perl-Moose" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-Moose on branch
master, which you are following:
1d343b0693bd79cc746d858686837bd833c528f9Paul HowarthUpdate to 2.2011



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-Moose/commits/master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
  38  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2c81054303   
remctl-3.14-1.el7
  14  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-5ae7f0e7c7   
python-pygit2-0.26.4-1.el7 libgit2-0.26.3-1.el7
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ce811a54c9   
roundcubemail-1.1.12-2.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-1ec98a14c5   
seamonkey-2.49.3-1.el7
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-1698223c96   
mysql-mmm-2.2.1-15.el7


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

cabal-rpm-0.12.3-1.el7
gnome-shell-extension-freon-34-1.el7
nodejs-deep-extend-0.5.1-1.el7

Details about builds:



 cabal-rpm-0.12.3-1.el7 (FEDORA-EPEL-2018-3756e5609c)
 RPM packaging tool for Haskell Cabal-based packages

Update Information:

Update from 0.9.10:  - run cabal update before cabal commands - add cabal-rpm
version header line to spec files - new option --missing: comments out missing
dependencies - put license files in lib subpackage - no longer append %_isa to C
BuildRequires - no longer leave leftover tmpdirs - devel packages now provide
doc subpackage for forward compatibility - new --hackage option to get package
version from Hackage not Stackage - fix handling of no exposed modules - various
other packaging fixes

ChangeLog:

* Tue May 15 2018 Jens Petersen  - 0.12.3-1
- build: remove erroneous tarball check
- refresh: use cblrpm for old cabal-rpm
* Thu Mar 29 2018 Jens Petersen  - 0.12.2-1
- diff: now supports CBLRPM_DIFF envvar to override "diff -u"
- build: attempt when missing rpms deps not available
* Wed Feb 21 2018 Jens Petersen  - 0.12.1-4
- fix build on epel7 ghc
* Wed Feb 21 2018 Jens Petersen  - 0.12.1-3
- add bcond for https
* Wed Feb 21 2018 Jens Petersen  - 0.12.1-2
- escape macro in previous changelog
* Tue Feb 20 2018 Jens Petersen  - 0.12.1-1
- new option --missing: comments out missing dependencies
- put license files in lib subpackage
- no longer append %_isa to C BuildRequires (#54)
- no longer leave leftover tmpdirs (#26)
- change 'cblrpm' to 'cabal-rpm' in documentation
* Fri Feb  9 2018 Igor Gnatenko  - 0.12-4
- Escape macros in %changelog
* Wed Feb  7 2018 Fedora Release Engineering  - 0.12-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild
* Fri Jan 26 2018 Jens Petersen  - 0.12-2
- rebuild
* Fri Nov 17 2017 Jens Petersen  - 0.12-1
- query stackage.org directly via https
- run cabal update before cabal commands
- devel packages now provide doc subpackage for forward compatibility
- new --hackage option to get package version from Hackage not Stackage
- do not add .cabal files containing "doc" to docs
- silence mock rpmbuild -bs warnings about undefined %ghc_version
* Mon Jul 31 2017 Jens Petersen  - 0.11.2-1
- fix cblrpm update --subpackage
- fix rpm installation when no sudo
- fix handling of no exposed modules
- fix license handling for selfdep binlib
* Mon Mar 13 2017 Jens Petersen  - 0.11.1-1
- update to 0.11.1 release:
- support for building meta (compat) lib packages
- fix invocation of optional stackage-query for updating to LTS
- preliminary --subpackage support for subpkgs of missing deps:
  including downloading, but update is not properly implemented yet
- new pkgver macro
- update do not reset release for subpkgs
* Fri Feb 24 2017 Jens Petersen  - 0.11-3
- refresh packaging to cabal-rpm-0.11.1
* Fri Feb 10 2017 Fedora Release Engineering  - 0.11-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
* Fri Jan 27 2017 Jens Petersen  - 0.11-1
- diff and update now follow package-version args
- update from Hackage now follows "Default available version"
- update tries to use stackage-query if installed to check latest Stackage
  version before falling back to latest Hackage
- refresh command now reads the cabal-rpm version header in the spec file and
  installs that version of cabal-rpm under ~/.cblrpm/ and uses it to make patch
* Tue Dec  6 2016 Jens Petersen  - 0.10.1-2
- quote dist macro in old changelog entry
* Tue Nov 29 2016 Jens Petersen  - 0.10.1-1
- update to 0.10.1:
- no longer need to remove License files from docdir
- use new ghc_fix_rpath macro
- include Contributors in docs
* Wed Jul 27 2016 Jens Petersen 

[Bug 1578594] perl-BSON-v1.6.0 is available

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-BSON-1.6.0-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-ae035cb55b

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

[rpms/perl-BSON] New Commits To "rpms/perl-BSON" (f28)

[pagure]

The following commits were pushed to the repo rpms/perl-BSON on branch
f28, which you are following:
d7e86f197e2acd419bb920d830c6366812c39770Jitka Plesnikova1.6.0 bump



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-BSON/commits/f28
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: [Design-team] Testing the wireframes of the Fedora Community App

[Abhishek Sharma]

>
> So I tried to add something to the calendar but none of the add to
> calendar links are active. So I don't know if I can actually say I
> completed the task or not?


It's done :) The main thing was *discoverability*. In the actual app,
native UI will pop up to add it to Calendar, so we skipped that screen.

On Wed, May 16, 2018 at 6:56 PM Máirín Duffy  wrote:

> Hey Abhishek,
>
> So I tried to add something to the calendar but none of the add to
> calendar links are active. So I don't know if I can actually say I
> completed the task or not?
>
> ~m
>
> Ar 05/16/2018 08:50 AM, scríobh Abhishek Sharma:
> > Hello Máirín
> >
> > The 4 tasks this appears to be assigning disappear when you get to
> > the mockups - can you provide the list of tasks so we can have it to
> > reference as we go through the mockups?
> > Also I don't see any kind of survey or other method of providing
> > feedback on each task? How should we go about doing that?
> >
> >
> > Thank you for pointing that out, I messed up.
> > Here's a link to the list of tasks and form to provide feedback:
> > https://goo.gl/forms/jr5GaP2YKtDqdypT2
> > Hope it helps.
> >
> > We'd love to have your feedback on specific screens as well, Please add
> > comments and suggestions here:
> >
> https://www.quant-ux.com/share.html?h=a2aa10albzVO4GPTETM7K8maNo3aObl9zCrhZx3lcvu7ylZRY5xY4eQ98lPy
> >
> >
> > On Wed, May 16, 2018 at 6:00 PM Máirín Duffy  > > wrote:
> >
> > Hi Abhishek!
> >
> > The 4 tasks this appears to be assigning disappear when you get to
> > the mockups - can you provide the list of tasks so we can have it to
> > reference as we go through the mockups?
> >
> > Also I don't see any kind of survey or other method of providing
> > feedback on each task? How should we go about doing that?
> >
> > Thanks,
> > ~m
> >
> > Ar 05/16/2018 03:52 AM, scríobh Abhishek Sharma:
> >  > Hello People!
> >  >
> >  > So we are working on revamping the Fedora Community App
> >  >
> > <
> https://play.google.com/store/apps/details?id=com.fedoraqa.fedora=en>,
> >  > and after an initial feedback and user testing session, we have an
> >  > improved wireframe ready for another round of testing.
> >  >
> >  > I was wondering if some of you can test this wireframe and
> > provide some
> >  > valuable feedback. In the process, you will be asked to do very
> > simple
> >  > tasks (which will hardly take 2 minutes) on a clickable
> prototype. We
> >  > can learn from the insights of testing to iterate on the design
> > of the
> >  > application. Basically what's working and what's not.
> >  >
> >  > Link to Test the Wireframes:
> >  >
> >
> https://www.quant-ux.com/test.html?h=a2aa10albzVO4GPTETM7K8maNo3aObl9zCrhZx3lcvu7ylZRY5xY4eQ98lPy
> >  >
> >  > Thanks a lot for your time!
> >  >
> >  > Best,
> >  > Abhishek
> >  >
> >  >
> >  >
> >  >
> >  > ___
> >  > design-team mailing list -- design-t...@lists.fedoraproject.org
> > 
> >  > To unsubscribe send an email to
> > design-team-le...@lists.fedoraproject.org
> > 
> >  >
> >
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1578594] perl-BSON-v1.6.0 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
 CC||jples...@redhat.com
   Fixed In Version||perl-BSON-1.6.0-1.fc29
   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

[rpms/perl-BSON] New Commits To "rpms/perl-BSON" (master)

[pagure]

The following commits were pushed to the repo rpms/perl-BSON on branch
master, which you are following:
d7e86f197e2acd419bb920d830c6366812c39770Jitka Plesnikova1.6.0 bump



To view more about the commits, visit:
https://src.fedoraproject.org/rpms/perl-BSON/commits/master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: [Design-team] Testing the wireframes of the Fedora Community App

[Máirín Duffy]

Hey Abhishek,

So I tried to add something to the calendar but none of the add to calendar 
links are active. So I don't know if I can actually say I completed the task or 
not?

~m

Ar 05/16/2018 08:50 AM, scríobh Abhishek Sharma:

Hello Máirín

    The 4 tasks this appears to be assigning disappear when you get to
    the mockups - can you provide the list of tasks so we can have it to
    reference as we go through the mockups?
    Also I don't see any kind of survey or other method of providing
    feedback on each task? How should we go about doing that?


Thank you for pointing that out, I messed up.
Here's a link to the list of tasks and form to provide feedback:
https://goo.gl/forms/jr5GaP2YKtDqdypT2
Hope it helps.

We'd love to have your feedback on specific screens as well, Please add
comments and suggestions here:
https://www.quant-ux.com/share.html?h=a2aa10albzVO4GPTETM7K8maNo3aObl9zCrhZx3lcvu7ylZRY5xY4eQ98lPy


On Wed, May 16, 2018 at 6:00 PM Máirín Duffy > wrote:

    Hi Abhishek!

    The 4 tasks this appears to be assigning disappear when you get to
    the mockups - can you provide the list of tasks so we can have it to
    reference as we go through the mockups?

    Also I don't see any kind of survey or other method of providing
    feedback on each task? How should we go about doing that?

    Thanks,
    ~m

    Ar 05/16/2018 03:52 AM, scríobh Abhishek Sharma:
 > Hello People!
 >
 > So we are working on revamping the Fedora Community App
 >
    ,
 > and after an initial feedback and user testing session, we have an
 > improved wireframe ready for another round of testing.
 >
 > I was wondering if some of you can test this wireframe and
    provide some
 > valuable feedback. In the process, you will be asked to do very
    simple
 > tasks (which will hardly take 2 minutes) on a clickable prototype. We
 > can learn from the insights of testing to iterate on the design
    of the
 > application. Basically what's working and what's not.
 >
 > Link to Test the Wireframes:
 >
    
https://www.quant-ux.com/test.html?h=a2aa10albzVO4GPTETM7K8maNo3aObl9zCrhZx3lcvu7ylZRY5xY4eQ98lPy
 >
 > Thanks a lot for your time!
 >
 > Best,
 > Abhishek
 >
 >
 >
 >
 > ___
 > design-team mailing list -- design-t...@lists.fedoraproject.org
    
 > To unsubscribe send an email to
    design-team-le...@lists.fedoraproject.org
    
 >


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

Running “telinit u” on glibc update

[Florian Weimer]

In Fedora, for historic reasons, we run “/sbin/telinit u” after 
installing a new glibc RPM package version.


Does this still make sense?  Should we remove the code which invokes 
telinit from the glibc package?


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

Re: [Design-team] Testing the wireframes of the Fedora Community App

[Abhishek Sharma]

Hello Máirín

The 4 tasks this appears to be assigning disappear when you get to the
> mockups - can you provide the list of tasks so we can have it to reference
> as we go through the mockups?
> Also I don't see any kind of survey or other method of providing feedback
> on each task? How should we go about doing that?


Thank you for pointing that out, I messed up.
Here's a link to the list of tasks and form to provide feedback:
https://goo.gl/forms/jr5GaP2YKtDqdypT2
Hope it helps.

We'd love to have your feedback on specific screens as well, Please add
comments and suggestions here:
https://www.quant-ux.com/share.html?h=a2aa10albzVO4GPTETM7K8maNo3aObl9zCrhZx3lcvu7ylZRY5xY4eQ98lPy


On Wed, May 16, 2018 at 6:00 PM Máirín Duffy  wrote:

> Hi Abhishek!
>
> The 4 tasks this appears to be assigning disappear when you get to the
> mockups - can you provide the list of tasks so we can have it to reference
> as we go through the mockups?
>
> Also I don't see any kind of survey or other method of providing feedback
> on each task? How should we go about doing that?
>
> Thanks,
> ~m
>
> Ar 05/16/2018 03:52 AM, scríobh Abhishek Sharma:
> > Hello People!
> >
> > So we are working on revamping the Fedora Community App
> >  >,
> > and after an initial feedback and user testing session, we have an
> > improved wireframe ready for another round of testing.
> >
> > I was wondering if some of you can test this wireframe and provide some
> > valuable feedback. In the process, you will be asked to do very simple
> > tasks (which will hardly take 2 minutes) on a clickable prototype. We
> > can learn from the insights of testing to iterate on the design of the
> > application. Basically what's working and what's not.
> >
> > Link to Test the Wireframes:
> >
> https://www.quant-ux.com/test.html?h=a2aa10albzVO4GPTETM7K8maNo3aObl9zCrhZx3lcvu7ylZRY5xY4eQ98lPy
> >
> > Thanks a lot for your time!
> >
> > Best,
> > Abhishek
> >
> >
> >
> >
> > ___
> > design-team mailing list -- design-t...@lists.fedoraproject.org
> > To unsubscribe send an email to
> design-team-le...@lists.fedoraproject.org
> >
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Testing the wireframes of the Fedora Community App

[Abhishek Sharma]

>
> > I just wanted to test and stumbled upon a problem:  no back or cancel
> button.


Hi Silvia, Can you let me know which particular screen are you referring
to? Perhaps, add a comment here
https://www.quant-ux.com/share.html?h=a2aa10albzVO4GPTETM7K8maNo3aObl9zCrhZx3lcvu7ylZRY5xY4eQ98lPy

Thank you for your time :)
On Wed, May 16, 2018 at 1:59 PM Silvia Sánchez  wrote:

>
> Hi!
>
> I just wanted to test and stumbled upon a problem:  no back or cancel
> button. There should be one in case one changes his/her mind.
>
>
> Kind regards,
> Silvia
> FAS:  Lailah
>
>
>
> On 16 May 2018 at 08:52, Abhishek Sharma  wrote:
>
>> Hello People!
>>
>> So we are working on revamping the Fedora Community App
>> ,
>> and after an initial feedback and user testing session, we have an improved
>> wireframe ready for another round of testing.
>>
>> I was wondering if some of you can test this wireframe and provide some
>> valuable feedback. In the process, you will be asked to do very simple
>> tasks (which will hardly take 2 minutes) on a clickable prototype. We can
>> learn from the insights of testing to iterate on the design of the
>> application. Basically what's working and what's not.
>>
>> Link to Test the Wireframes:
>> https://www.quant-ux.com/test.html?h=a2aa10albzVO4GPTETM7K8maNo3aObl9zCrhZx3lcvu7ylZRY5xY4eQ98lPy
>>
>> Thanks a lot for your time!
>>
>> Best,
>> Abhishek
>>
>>
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Design-team] Testing the wireframes of the Fedora Community App

[Máirín Duffy]

Hi Abhishek!

The 4 tasks this appears to be assigning disappear when you get to the mockups 
- can you provide the list of tasks so we can have it to reference as we go 
through the mockups?

Also I don't see any kind of survey or other method of providing feedback on 
each task? How should we go about doing that?

Thanks,
~m

Ar 05/16/2018 03:52 AM, scríobh Abhishek Sharma:

Hello People!

So we are working on revamping the Fedora Community App
,
and after an initial feedback and user testing session, we have an
improved wireframe ready for another round of testing.

I was wondering if some of you can test this wireframe and provide some
valuable feedback. In the process, you will be asked to do very simple
tasks (which will hardly take 2 minutes) on a clickable prototype. We
can learn from the insights of testing to iterate on the design of the
application. Basically what's working and what's not.

Link to Test the Wireframes:
https://www.quant-ux.com/test.html?h=a2aa10albzVO4GPTETM7K8maNo3aObl9zCrhZx3lcvu7ylZRY5xY4eQ98lPy

Thanks a lot for your time!

Best,
Abhishek




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


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

[Bug 1578812] New: perl-Moose-2.2011 is available

[bugzilla]

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

Bug ID: 1578812
   Summary: perl-Moose-2.2011 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Moose
  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, lkund...@v3.sk,
p...@city-fan.org, perl-devel@lists.fedoraproject.org



Latest upstream release: 2.2011
Current version/release in rawhide: 2.2010-1.fc28
URL: http://search.cpan.org/dist/Moose/

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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F28 `dnf update` "Error: Failed to synchronize cache for repo 'fedora-debuginfo'"

[Adrian Reber]

On Wed, May 16, 2018 at 10:53:10AM +0200, Stephan Bergmann wrote:
> On F28, `dnf update` recently started to fail for me with "Error: Failed to
> synchronize cache for repo 'fedora-debuginfo'":
> 
> > $ sudo dnf -vv --disablerepo=\* --enablerepo=fedora-debuginfo --refresh 
> > makecache
> > Loaded plugins: builddep, config-manager, copr, debug, debuginfo-install, 
> > download, generate_completion_cache, needs-restarting, playground, 
> > repoclosure, repograph, repomanage, reposync, system-upgrade, versionlock
> > DNF version: 2.7.5
> > cachedir: /var/cache/dnf
> > Making cache files for all metadata files.
> > fedora-debuginfo: has expired and will be refreshed.
> > Cannot download 
> > 'https://mirrors.fedoraproject.org/metalink?repo=fedora-debug-28=x86_64':
> >  Cannot prepare internal mirrorlist: file "repomd.xml" was not found in 
> > metalink.
> > Error: Failed to synchronize cache for repo 'fedora-debuginfo'

Thanks for the report. Fixing it right now in MirrorManager. The new
directory layout for the debuginfo packages which sometimes contains
'tree/' in the path and sometimes it does not confuses the part of
MirrorManager which tries to detect repositories. Should be fixed soon.

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

[Bug 1517572] Please add unar dependency/ configuration for *.rar and comment *.lrz support

[bugzilla]

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



--- Comment #17 from Juan Orti  ---
I'd need to package the unar-wrapper, which I don't see the code around. I also
think it will be better to be included in the unar package.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1546092] amavisd-new ignores $final_spam_destiny directive

[bugzilla]

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

Juan Orti  changed:

   What|Removed |Added

 CC||haliae...@ymail.com
  Flags||needinfo?(haliaetos@ymail.c
   ||om)



--- Comment #1 from Juan Orti  ---
Works fine for me. Can you attach your full amavisd.conf?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1551203] amavisd-release and amavisd-submit use wrong default socket path

[bugzilla]

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

Juan Orti  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |RAWHIDE
Last Closed|2018-03-13 06:58:24 |2018-05-16 05:05:16



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

F28 `dnf update` "Error: Failed to synchronize cache for repo 'fedora-debuginfo'"

[Stephan Bergmann]

On F28, `dnf update` recently started to fail for me with "Error: Failed 
to synchronize cache for repo 'fedora-debuginfo'":



$ sudo dnf -vv --disablerepo=\* --enablerepo=fedora-debuginfo --refresh 
makecache
Loaded plugins: builddep, config-manager, copr, debug, debuginfo-install, 
download, generate_completion_cache, needs-restarting, playground, repoclosure, 
repograph, repomanage, reposync, system-upgrade, versionlock
DNF version: 2.7.5
cachedir: /var/cache/dnf
Making cache files for all metadata files.
fedora-debuginfo: has expired and will be refreshed.
Cannot download 
'https://mirrors.fedoraproject.org/metalink?repo=fedora-debug-28=x86_64': Cannot 
prepare internal mirrorlist: file "repomd.xml" was not found in metalink.
Error: Failed to synchronize cache for repo 'fedora-debuginfo'


and


curl 
'https://mirrors.fedoraproject.org/metalink?repo=fedora-debug-28=x86_64'

http://www.metalinker.org/; type="dynamic" pubdate="Wed, 16 May 2018 
08:44:47 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.org/mirrormanager;>




claims it's both available and not available.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Testing the wireframes of the Fedora Community App

[Silvia Sánchez]

Hi!

I just wanted to test and stumbled upon a problem:  no back or cancel
button. There should be one in case one changes his/her mind.


Kind regards,
Silvia
FAS:  Lailah



On 16 May 2018 at 08:52, Abhishek Sharma  wrote:

> Hello People!
>
> So we are working on revamping the Fedora Community App
> ,
> and after an initial feedback and user testing session, we have an improved
> wireframe ready for another round of testing.
>
> I was wondering if some of you can test this wireframe and provide some
> valuable feedback. In the process, you will be asked to do very simple
> tasks (which will hardly take 2 minutes) on a clickable prototype. We can
> learn from the insights of testing to iterate on the design of the
> application. Basically what's working and what's not.
>
> Link to Test the Wireframes: https://www.quant-ux.com/test.html?h=
> a2aa10albzVO4GPTETM7K8maNo3aObl9zCrhZx3lcvu7ylZRY5xY4eQ98lPy
>
> Thanks a lot for your time!
>
> Best,
> Abhishek
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Testing the wireframes of the Fedora Community App

[Abhishek Sharma]

Hello People!

So we are working on revamping the Fedora Community App
,
and after an initial feedback and user testing session, we have an improved
wireframe ready for another round of testing.

I was wondering if some of you can test this wireframe and provide some
valuable feedback. In the process, you will be asked to do very simple
tasks (which will hardly take 2 minutes) on a clickable prototype. We can
learn from the insights of testing to iterate on the design of the
application. Basically what's working and what's not.

Link to Test the Wireframes:
https://www.quant-ux.com/test.html?h=a2aa10albzVO4GPTETM7K8maNo3aObl9zCrhZx3lcvu7ylZRY5xY4eQ98lPy

Thanks a lot for your time!

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