[Bug 1748057] Request for branching to epel-8

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

Link ID||Red Hat Bugzilla 1663063
   ||Red Hat Bugzilla 1746898



--- Comment #1 from Petr Pisar  ---
I will add perl-Convert-ASN1
 and perl-LDAP
 packages into EPEL.
In case the packages will be added into RHEL (bugs #1663063, #1746898), I will
remove them from EPEL.

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

[Bug 1748057] Request for branching to epel-8

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

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



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

[EPEL-devel] XML::Feed.pm perl on CentOS 7

[Lars Noodén]

I'm looking for CPAN's XML::Feed.pm for perl 5 for centos 7 via yum but
not finding anything for it (e.g. perl-XML-Feed.noarch) in the
repositories.  I have the base, epel, extras, and updates repositories
available.

$ yum -q search all XML-Feed
Warning: No matches found for: XML-Feed

$ grep PRETTY /etc/os-release
PRETTY_NAME="CentOS Linux 7 (Core)"

Is there an additional package repository containing CPAN material for
CentOS 7 which I must add in order to get XML::Feed?

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

Re: Fedora Samba DC for what purpose it is released in Fedora ?

[Alexander Bokovoy]

On Mon, 02 Sep 2019, Nico Kadel-Garcia wrote:

On Mon, Sep 2, 2019 at 9:25 PM Robert Marcano  wrote:


On 9/2/19 4:52 PM, Nico Kadel-Garcia wrote:
> On Mon, Sep 2, 2019 at 3:33 PM Alexander Bokovoy  wrote:
>>
>> On Mon, 02 Sep 2019, Dario Lesca wrote:
>>> Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha scritto:
 I switched to run Samba DCs on a container with non Fedora / RHEL /
 CentOS provided RPMs.
>>>
>>> Thank Robert for reply.
>>>
>>> Then why don't release samba compiled with Heimdal kerberos?
>>>
>>> Just change a flag in build time, and all can use it into a production
>>> environment.
>> We do not support Heimdal builds in Fedora. It is not possible to reuse
>> components of Samba built against Heimdal within other applications
>> compiled against MIT Kerberos. This is, in particular, a show-stopper
>> for FreeIPA and SSSD integration.
>
> My personal experience is that this is not true. sssd in a recent
> Fedora (Fedora 29 last year) works just fine against an honest-to-god
> Samba 4.9 domain controller on RHEL 7. I've not tested tested it with
> samba 4.11rc2 yeat, as I'm still working on that port. sssd also works
> against a real AD controller. sssd does not rely on a freeipa server.
> It has genuinely unfortunate behavior of pre-downloading the *entire*
> LDAP tree, and breaking if it can't complete this, but that's another
> issue that won't be visible in most small test environments with local
> domain controllers.

The parent poster is refering to having two Kerberos implementations on
the same process, not from two different machines. For example, an
application linking against Samba libraries with Heimdal and at the same
time linking with system MIT Kerberos for another features of that
application unrelated with Samba.


Sorry to sound critical, but this is irrelevant because, to use domain
controller enabled Samba, it compiles its own internal Kerberos. There
are other system libraries which Samba shares, such as libtalloc and
libldb, but for the comain controller. As best I can tell with sssd,
it's not been a problem. I did not run FreeIPA at all after some
failed attempts, and found  with Samba compatible completely with AD
and the clients able to work, I had no use for it. So the libraries
did not overlap.

SSSD itself is buildable against Heimdal. However, for quite a number of
features it uses MIT Kerberos-provided APIs that do not exist in Heimdal.
This means that when it is built against Heimdal, you cannot use those
features (2FA support, prompting in Kerberos clients, etc).

If you have SSSD built against MIT Kerberos and Samba AD built against
internal Heimdal version, the tools from Samba AD would be linked to
Heimdal libraries. This also means they would be expecting Kerberos
credential cache format the same way as Heimdal expects. If those
credential caches produced by SSSD or a normal kinit (which is MIT
Kerberos in Fedora), they may lose some details/flags or be simply
inaccessible. For example, Heimdal does not know anything about KEYRING
and DIR credential cache types. Also, there is a difference in flags
stored in FILE ccaches.


If FreeIPA were dropped from Fedora, would there remain any reason to
prefer MIT Kerberos over Heimdal Kerberos?  It's not that I object to
the MIT Kerberos, I know several of the authors personally as old
friends. But that's not a reason to prefer the software.

As I said, you are in you own right to build infrastructure as you want.
For example, in modules or in COPR. As a group of maintainers for MIT
Kerberos, Samba, FreeIPA, and SSSD in Fedora we are trying to deliver a
uniform working solution that spans servers and workstations altogether.
As far as I know, one biggest missing piece for Samba AD DC with MIT
backend is a bug with GPO enforcement that is tracked upstream. There
are few others but they are of lesser importance.

When we decided to mark MIT backend for Samba AD as experimental at
Samba upstream, it was our decision (mine and Andrew Bartlett) to allow
MIT support to brew a bit at a slower pace. Samba team's opinion is to
get rid of Heimdal integration eventually and concentrate on a single
supported Kerberos implementation -- MIT Kerberos. It takes time and is
currently suspended due to crypto consolidation work we are doing for
various reasons[1] but we'll get there. There are not so many developers
who are willing to work on core infrastructure components.

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

[Bug 1748169] New: perl-MCE-1.847 is available

[bugzilla]

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

Bug ID: 1748169
   Summary: perl-MCE-1.847 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-MCE
  Keywords: FutureFeature, Triaged
  Assignee: p...@city-fan.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Latest upstream release: 1.847
Current version/release in rawhide: 1.846-1.fc32
URL: http://search.cpan.org/dist/MCE/

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

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

Re: Fedora Workstation and disabled by default firewall

[Christopher]

On Tue, Sep 3, 2019 at 12:26 AM John Harris  wrote:
> There is not a single service in Fedora that is broken by the firewall
> running. You simply have to open the port before it can be accessed from a
> remote system, which is by design. Basic access control, a security feature.

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

Re: skychart package updates broken after module retirement

[John Harris]

On Sunday, September 1, 2019 2:54:32 AM MST Mattia Verga via devel wrote:
> Recently, I requested to retire Skychart module and this has been done 
> in F31 and F32:
> https://pagure.io/releng/issue/8640
> 
> Now I'm trying to push an update to Skychart classic RPMs, Koji shows it 
> as tagged both in F30-updates-testing and F31-updates-testing, but 
> there's no sign of them in the repositories:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1366604
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1366605
> 
> # dnf repository-packages updates-testing info skychart
> Ultima verifica della scadenza dei metadati: 0:07:19 fa il dom 1 set 
> 2019, 11:28:40.
> Errore: Nessun pacchetto corrispondente
> 
> Could the module retirement and the missing update be related?

It's unfortunate that nobody thought modules through, and we just jumped right 
to implementation. It'd require a lot of work to fix the mess caused by 
modules now.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

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

Re: Intention to retire Release Notes RPM

[John Harris]

On Monday, August 5, 2019 4:42:31 AM MST Martin Kolman wrote:
> On Sat, 2019-08-03 at 03:45 -0400, Neal Gompa wrote:
> 
> > On Sat, Aug 3, 2019 at 3:10 AM Brian (bex) Exelbierd
> >  wrote:
> > 
> > > Hi All,
> > > 
> > > Barring objection, I plan to retire the release notes package from
> > > Fedora on or after August 9, 2019.  The package has not been updated
> > > since F28.  Despite the fact that we have literally shipped a package
> > > containing the F28 release notes in F29 and F30, there have been no
> > > comments.  This has been discussed with the docs team and is
> > > supported.  I am not aware of any dependencies and I believe it was
> > > removed from release criteria in F29.
> > > 
> > > I will run `fedpkg retire` and further request removal via
> > > https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=rawhide
> > > =fedora-obsolete-packages
 
> > > Please reply on list if you have any questions or concerns.
> > > 
> > 
> > 
> > Does Anaconda not support showing the release notes _anywhere_? That
> > was the original impetus for shipping it that way...
> 
> There is currently no screen in either graphical or text interface of
> Anaconda that would show Fedora release notes.
> > 
> > 
> > 
> > -- 
> > 真実はいつも一つ！/ Always, there's only one truth!

It might be better to just show that on the portion of the installer shown 
while the system is installing. That way, the user could read about the new 
stuff in this release while waiting for the install to complete, along with 
the banners at the bottom.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

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

Re: Debates/back and forths

[John Harris]

On Sunday, September 1, 2019 6:22:04 AM MST Gerald B. Cox wrote:
> John you're comparing apples and oranges.  One is active the other is
> passive.  One uses your space allocation the other doesn't.

Sorry, what? What space allocation? If you're talking about emails, my Maildir 
hasn't reached a size over 1 GiB in over two years of being on very high 
traffic mailing lists, including kernel lists.

The two are *exactly the same*. Clicking on the button makes it so you don't 
receive notifications about that thread anymore. Additionally, and this covers 
lists other than Fedora hosted mailing lists, on most clients you can right 
click the thread and "Ignore", "Delete" or "Create Filter From Thread" and 
pipe that thread to the trash.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

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

Re: Better interactivity in low-memory situations

[John Harris]

On Tuesday, August 20, 2019 10:48:06 PM MST John Harris wrote:
> On Sunday, August 18, 2019 4:33:47 AM MST Gordan Bobic wrote:
> 
> > On Sun, Aug 11, 2019 at 10:36 AM  wrote:
> > 
> > > This seems like a distraction from the real goal here, which is to
> > > ensure Fedora remains responsive under heavy memory pressure,
> > 
> > 
> > I think this is an overwhelmingly important point, and as somebody
> > regularly working with ARM machines with tiny amounts of RAM, it is of
> > considerable interest to me.
> > I typically use CentOS because stability is important to me, but most
> > worthwhile things filter to there, so I hope what I'm about to say is not
> > _too_ deprecated.
> > 
> > 1) Compile options
> > From what I can tell from rpm macro options, default on C7 seems to be
> > -O2.
 -Os seems to help in most cases.
> > Adding -ffunction-sections -fdata-sections to defaults can help
> > considerably in producing smaller binaries, and is not the default.
> > Linking with -Wl,--gc-sections helps a lot and is not the default
> > Extensive stripping seems to already be the default (--strip-unneeded,
> > removal of .comment and .note sections)
> > 
> > 2) Runtime condiguration
> > Default stack size is 8192 (ulimit -s). This unnecessarily eats a
> > considerably amount of memory. I have yet to see anything that actually
> > experiences problems with 1M.
> > 
> > 3) zram
> > This was mentioned earlier in the thread, and on most of my systems,
> > memory constrained or otherwise, unless I have an overwhelming reason
> > not to, I run with zram swap equal in size to RAM with lz4 compression
> > and
> > vm.swappiness=100. I typically see compression ratios between 2:1 and 3:1
> > in zram, so on a system with, say, 10GB of RAM, it would provide 10GB of
> > very fast swap at a cost of 3-5GB of RAM. This seems like a favourable
> > trade off, especially on systems with extremely constrained RAM (e.g. ARM
> > devices with 512MB of RAM).
> > 
> > I'm sure there is more that can be done, but this seems like a good start
> > as far as the cost / benefit is concerned.
> 
> 
> Python, Lua and a few other common programs can have issues with a stack
> size  of 1MiB.
> 
> -- 
> John M. Harris, Jr. 
> Splentity
> https://splentity.com/

I would also like to add that I don't see how it's even possible to run into a 
low-memory scenario on a system with 10 GiB (That's a *lot* of memory! I run 
on a Core 2 Duo based system that can support a max of 8 GiB as my daily 
driver.) often enough to have a problem with oom_killer.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

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

Re: Fedora Workstation and disabled by default firewall

[John Harris]

On Sunday, September 1, 2019 4:13:10 AM MST mcatanz...@gnome.org wrote:
> On Sat, Aug 31, 2019 at 6:37 PM, Nico Kadel-Garcia  
> wrote:
> 
> > If 30 years in DevOps and system security in both large and small
> > networks count for anything, this makes *complete* sense. The
> > distinction between a "Workstation" deployment and a "Server" or
> > "Everything" deployment should not include leaving the Workstation
> > completely vulnerable to the most casual script kiddie attacks after
> > they install *any* services, especially including MySQL, DNS, Samba,
> > or Tomcat, Jenkins, or anything else.
> 
> 
> Well that's why installed network services are disabled by default in 
> Fedora, unless the package receives an exception from FESCo. This isn't 
> Debian where installing a package is expected to result in the service 
> being up and running. If you 'systemctl start' your service and the 
> firewall breaks it, that's just annoying.
> 
> Michael

There is not a single service in Fedora that is broken by the firewall 
running. You simply have to open the port before it can be accessed from a 
remote system, which is by design. Basic access control, a security feature.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

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

[Bug 1747726] perl-Git-Repository-1.324 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Git-Repository-1.324-1.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-21d1a12ca6

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

Re: Fedora Samba DC for what purpose it is released in Fedora ?

[Nico Kadel-Garcia]

On Mon, Sep 2, 2019 at 9:25 PM Robert Marcano  wrote:
>
> On 9/2/19 4:52 PM, Nico Kadel-Garcia wrote:
> > On Mon, Sep 2, 2019 at 3:33 PM Alexander Bokovoy  
> > wrote:
> >>
> >> On Mon, 02 Sep 2019, Dario Lesca wrote:
> >>> Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha scritto:
>  I switched to run Samba DCs on a container with non Fedora / RHEL /
>  CentOS provided RPMs.
> >>>
> >>> Thank Robert for reply.
> >>>
> >>> Then why don't release samba compiled with Heimdal kerberos?
> >>>
> >>> Just change a flag in build time, and all can use it into a production
> >>> environment.
> >> We do not support Heimdal builds in Fedora. It is not possible to reuse
> >> components of Samba built against Heimdal within other applications
> >> compiled against MIT Kerberos. This is, in particular, a show-stopper
> >> for FreeIPA and SSSD integration.
> >
> > My personal experience is that this is not true. sssd in a recent
> > Fedora (Fedora 29 last year) works just fine against an honest-to-god
> > Samba 4.9 domain controller on RHEL 7. I've not tested tested it with
> > samba 4.11rc2 yeat, as I'm still working on that port. sssd also works
> > against a real AD controller. sssd does not rely on a freeipa server.
> > It has genuinely unfortunate behavior of pre-downloading the *entire*
> > LDAP tree, and breaking if it can't complete this, but that's another
> > issue that won't be visible in most small test environments with local
> > domain controllers.
>
> The parent poster is refering to having two Kerberos implementations on
> the same process, not from two different machines. For example, an
> application linking against Samba libraries with Heimdal and at the same
> time linking with system MIT Kerberos for another features of that
> application unrelated with Samba.

Sorry to sound critical, but this is irrelevant because, to use domain
controller enabled Samba, it compiles its own internal Kerberos. There
are other system libraries which Samba shares, such as libtalloc and
libldb, but for the comain controller. As best I can tell with sssd,
it's not been a problem. I did not run FreeIPA at all after some
failed attempts, and found  with Samba compatible completely with AD
and the clients able to work, I had no use for it. So the libraries
did not overlap.

If FreeIPA were dropped from Fedora, would there remain any reason to
prefer MIT Kerberos over Heimdal Kerberos?  It's not that I object to
the MIT Kerberos, I know several of the authors personally as old
friends. But that's not a reason to prefer the software.

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

[Fedocal] Reminder meeting : Modularity Team (weekly)

[nils]

Dear all,

You are kindly invited to the meeting:
   Modularity Team (weekly) on 2019-09-03 from 15:00:00 to 16:00:00 UTC
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Modularity Team.

More information available at: [Modularity Team 
Docs](https://docs.pagure.org/modularity/)

The agenda for the meeting is available as flagged tickets [in the Modularity 
repository](https://pagure.io/modularity/issues?status=Open=Meeting).



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

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

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

[updates]

The following Fedora EPEL 8 Security updates need testing:
 Age  URL
  10  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-fabd190d13   
clamav-0.101.4-1.el8


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

geos-3.7.2-1.el8
libgeotiff-1.5.1-1.el8
mongo-c-driver-1.15.1-1.el8
proj-6.2.0-1.el8

Details about builds:



 geos-3.7.2-1.el8 (FEDORA-EPEL-2019-7d447865d1)
 GEOS is a C++ port of the Java Topology Suite

Update Information:

Initial packaging for EPEL 8.

References:

  [ 1 ] Bug #1741566 - Request to package geos for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1741566




 libgeotiff-1.5.1-1.el8 (FEDORA-EPEL-2019-9a813314e6)
 GeoTIFF format library

Update Information:

Initial packaging for EPEL 8

References:

  [ 1 ] Bug #1741545 - Request to package libgeotiff for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1741545




 mongo-c-driver-1.15.1-1.el8 (FEDORA-EPEL-2019-ad0e59ac8e)
 Client library written in C for MongoDB

Update Information:

mongo-c-driver is a client library written in C for MongoDB.




 proj-6.2.0-1.el8 (FEDORA-EPEL-2019-379d915ea9)
 Cartographic projection software (PROJ)

Update Information:

Initial packaging for EPEL 8.

References:

  [ 1 ] Bug #1741543 - Request to package proj for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1741543


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

[Bug 1747549] perl-PPIx-Regexp-0.067 is available

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-PPIx-Regexp-0.067-1.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-497b4dea59

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

[Bug 1747170] perl-Date-Manip-6.78 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Date-Manip-6.78-1.fc30 has been pushed to the Fedora 30 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-9ff6198c59

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

[389-devel] 389 DS nightly 2019-09-03 - 95% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2019/09/03/report-389-ds-base-1.4.1.6-20190902git0a34389.fc30.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org

Re: Fedora Samba DC for what purpose it is released in Fedora ?

[Robert Marcano]

On 9/2/19 4:52 PM, Nico Kadel-Garcia wrote:

On Mon, Sep 2, 2019 at 3:33 PM Alexander Bokovoy  wrote:


On Mon, 02 Sep 2019, Dario Lesca wrote:

Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha scritto:

I switched to run Samba DCs on a container with non Fedora / RHEL /
CentOS provided RPMs.


Thank Robert for reply.

Then why don't release samba compiled with Heimdal kerberos?

Just change a flag in build time, and all can use it into a production
environment.

We do not support Heimdal builds in Fedora. It is not possible to reuse
components of Samba built against Heimdal within other applications
compiled against MIT Kerberos. This is, in particular, a show-stopper
for FreeIPA and SSSD integration.


My personal experience is that this is not true. sssd in a recent
Fedora (Fedora 29 last year) works just fine against an honest-to-god
Samba 4.9 domain controller on RHEL 7. I've not tested tested it with
samba 4.11rc2 yeat, as I'm still working on that port. sssd also works
against a real AD controller. sssd does not rely on a freeipa server.
It has genuinely unfortunate behavior of pre-downloading the *entire*
LDAP tree, and breaking if it can't complete this, but that's another
issue that won't be visible in most small test environments with local
domain controllers.


The parent poster is refering to having two Kerberos implementations on 
the same process, not from two different machines. For example, an 
application linking against Samba libraries with Heimdal and at the same 
time linking with system MIT Kerberos for another features of that 
application unrelated with Samba.




Freeipa. I started setting up, realized it was going to take
months to replace existing structures and gain me *absolutely nothing*
compared to using the built-in AD or Samba systems already in my
network, and maybe tuning them slightly better.


If someone want test MIT version re-change the flag and rebuild it  by
himself .. or release also a samba suite with a specific name (es.
samba-mit-...).

Samba DC is a useful solution in soma case, It is an inconvenience that
we must switch to another distro o use a third part repos  because this
suite into Fedora/RHEL/Centos is a experimental version

You may create your own COPR repository and support your own build
there. It is up to you to support that solution.


In the case of Samba, the support community is quite large. It's been
an active free software project, used worldwide and across multiple
operating systems, since the 1990's. I can vouch for that personally,
I published my first port of it for SunOS in roughly 1998. Nearly
every bulk storage device in the world uses it to provide CIFS
fileshares, many of those bulk storage devices with full domain
controller services available if not activated. It's one of the
cheapest ways to replace an AD domain controller.

FreeIPA does not have anywhere near the user and developer
community for servers. And sssd well, I've used it for Fedora and
RHEL, because it's a convenient wrapper for what I used to have to do
with the "net ads" command from Samba and is useful for admins who
can't be bothered to put more than one command in a shell script. But
its configurations are confusing, Do not get me *going* on the
interactions of sssd with the very limited "authconfig" command line
tool. And you really, really don't want to get me going on how sssd
insists on pre-loading *all* the upstream LDAP trees, works for 30
seconds and then crashes when the pre-load times out, and there is no
fix or way to restart *just that sssd LDAP sub-daemon*. The sssd damon
wrapping customized sssd subdamons, instead of simply using the
built-in system LDAP daemons is destabilizing and completely
unnecessary.

I'll take a Samba client in a heartbeat over the sssd mess in any even
slightly complex environment. And since the upstream for both sssd and
Samba clients can be the more popular and more supportable AD or Samba
server,  there has been little point to more than the most casual look
at a FreeIPA server.

Are there any significant sets of systems or clients reliant on
FreeIPA specific features? Because maintaining it does not seem worth
the developer effort if not client specifically requires it. I realize
it may be a big vendor project over at Red Hat, but does *anyone*  use
it out of a specific software need?


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland


Sorry to chew on your employer, who are very helpful generally and
whose work I normally appreciate. sssd and freeipa have not been
examples of Red Hat's best work and community integration


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

[Bug 1747549] perl-PPIx-Regexp-0.067 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-PPIx-Regexp-0.067-1.fc31 has been pushed to the Fedora 31 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-0cb94dfc85

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

[Bug 1747079] perl-File-Next-1.18 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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

[Bug 1746257] Upgrade perl-File-Next to 1.18

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-File-Next-1.18-1.fc31 has been pushed to the Fedora 31 testing repository.
If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-b5f8ae29e2

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

powertop vs upower, troubleshooting battery remaining

[Chris Murphy]

This is an hp spectre running Fedora 30 Workstation. On Fedora 29,
there was fairly close agreement between powertop and upower and the
time estimates were sane.

Something's wonky on Fedora 30 and I'm not sure where to begin
troubleshooting, although I posted a message on the upstream powertop
list.

This is what I'm seeing.
https://paste.fedoraproject.org/paste/3M7euUWnqZG07KKJQpRQ-w/raw

powertop says 108 hours remaining, upower first says 6.8 hours
remaining which is much more plausible, but then merely 4 minutes
later battery has gone from 93% to 77%, and to a 22 minute remaining
estimate. Really? One says the battery reports 268mW of discharge, the
other reports 61W discharge. Neither of those is possible.


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

Re: Sponsorship request

[Miro Hrončok]

On 03. 09. 19 0:33, Fabio Valentini wrote:

I can't sponsor you since I'm not a member of the required account
group


I think it's time you become a member of the required account group.

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

Re: [HEADS UP] Fedora 32 Python 3.8 rebuilds have started in a side tag

[Miro Hrončok]

On 02. 09. 19 18:58, Mat Booth wrote:
On Fri, 23 Aug 2019 at 17:39, Miro Hrončok > wrote:


On 23. 08. 19 17:15, Vít Ondruch wrote:
 >
 > Dne 23. 08. 19 v 17:05 Kaleb Keithley napsal(a):
 >>
 >>
 >> On Wed, Aug 21, 2019 at 1:23 PM Miro Hrončok mailto:mhron...@redhat.com>
 >> >> wrote:
 >>
 >>     On 15. 08. 19 0:18, Miro Hrončok wrote:
 >>     > Hello, in order to deliver Python 3.8, we are running a 
coordinated
 >>     rebuild in a
 >>     > side tag.
 >>     >
 >>
 >>     The side tag was merged. Build in regular rawhide now. Thanks.
 >>
 >>
 >> /me wonders why my `dnf update`  on my f32/rawhide box isn't updating to
 >> python-3.8. Should it be?
 >
 >
 > I guess there was no Rawhide compose yet, which would contain the 
changes. I
 > would not be surprised if the merge broke the compose.

We are monitoring it to firefight any such breakage, but the current
breakage is
not relevant to 3.8.


I noticed that eclipse-pydev stopped building with the introduction of python 
3.8. Can you offer any clue how to fix it?


Here is the log, you can see that the cython-based debugging extension when 
built against python 3.8 is failing:

https://kojipkgs.fedoraproject.org//work/tasks/5618/37405618/build.log


See also https://bugzilla.redhat.com/show_bug.cgi?id=1693641


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

[389-devel] Review reminder :)

[William Brown]

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

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

Thanks! 


--
Sincerely,

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

Re: skychart package updates broken after module retirement

[Kevin Fenzi]

On 9/1/19 2:54 AM, Mattia Verga via devel wrote:
> Recently, I requested to retire Skychart module and this has been done 
> in F31 and F32:
> https://pagure.io/releng/issue/8640
> 
> Now I'm trying to push an update to Skychart classic RPMs, Koji shows it 
> as tagged both in F30-updates-testing and F31-updates-testing, but 
> there's no sign of them in the repositories:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1366604
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1366605
> 
> # dnf repository-packages updates-testing info skychart
> Ultima verifica della scadenza dei metadati: 0:07:19 fa il dom 1 set 
> 2019, 11:28:40.
> Errore: Nessun pacchetto corrispondente
> 
> Could the module retirement and the missing update be related?

It seems in testing ok on the master mirrors...

https://dl.fedoraproject.org/pub/fedora/linux/updates/testing/30/Everything/SRPMS/Packages/s/skychart-4.1.1-5.4000svn.fc30.src.rpm

kevin



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

[389-devel] Re: Docker releases of 389

[William Brown]

> On 3 Sep 2019, at 00:19, Matus Honek  wrote:
> 
> On Mon, Sep 2, 2019 at 3:43 AM William Brown  wrote:
>> 
>> Hey all,
>> 
>> RC images have been pushed: https://hub.docker.com/r/389ds/dirsrv
> 
> First, I'm not with processes on Docker Hub, so please bear with me...
> :) I don't see a Dockerfile tab on the page -- is this because of how
> the OSB container pipeline works? (hint: I usually don't trust the
> builds on the Docker Hub for which there is not a Dockerfile)

Yes, that's correct. It's because it's built on OBS so I just push the image 
directly. It's useful because it means when I upload new source, it 
automatically builds the container too.

Saying this, the Dockerfile as used in OBS could be used on dockerhub if there 
are transparency concerns? Alternately, I could link to the source repo? 
Thoughts? 

> 
>> 
>> I'll try to accomodate as much feedback as possible, aiming for 1.4.2 to be 
>> out first fully supported release. Sounds okay?
>> 
>>> On 29 Aug 2019, at 12:55, William Brown  wrote:
>>> 
>>> Hi all,
>>> 
>>> I've been wanting this for a long time and I think we're almost there - I'd 
>>> like us to start offering docker images of 389 Directory Server as part of 
>>> our upstream release process.
>>> 
>>> I have discussed this with Mark already and we both think we are reasonably 
>>> happy with the idea and the state we're in.
>>> 
>>> -- The Technical Process and Details:
>>> 
>>> As there is significant interest within SUSE for containerised 389, as well 
>>> as open tooling as part of build.opensuse.org, the current proposed process 
>>> is:
>>> 
>>> Source Release -> OBS:network:ldap -> OBS:389-ds-container -> docker hub
>>> 
>>> Because this pipeline is automated between source to the container, and 
>>> this is already part of my responsibility as the SUSE package manager, it's 
>>> a small amount of effort to then mirror the container to docker hub.
>>> 
>>> I have already established an organisation on docker hub, and will be 
>>> giving Mark access to be able to manage this as well.
>>> 
>>> https://cloud.docker.com/u/389ds/repository/list
>>> 
>>> Initially we'll name the image as:
>>> 
>>> 389ds/dirsrv:1.4.rc
>>> 
>>> Once we are happy with the process, and have received some community 
>>> feedback we'll move to:
>>> 
>>> 389ds/dirsrv:1.4.1
>>> 389ds/dirsrv:1.4.2
>>> 389ds/dirsrv:1.4 # points to latest 1.4.X
>>> 389ds/dirsrv:latest # points to newest version
>>> 
>>> We would of course encourage people to use the "latest" tag.
>>> 
>>> -- Support
>>> 
>>> During the rc phase we would announce that the container support is "best 
>>> effort" and we'll obviously work to resolve issues, but it's not suitable 
>>> for production work loads.
>>> 
>>> Once we are happy with this for a few releases, we'll move to the same 
>>> support levels as our normal releases - best effort community, and patch 
>>> backporting as we normally do. For official support, contact a vendor like 
>>> SUSE or Red Hat.
>>> 
>>> -- Future / Downstreams
>>> 
>>> The design of the container integration is such that we should be able to 
>>> easily swap the suse/fedora/rhel as the base image, so downstreams should 
>>> be able to easily adopt the dscontainer tool and have customers pivot from 
>>> the upstream image to their vendor image quite easily.
>>> 
>>> A future container option is to supply a tools container that has a shell + 
>>> ds* tools, so that you can have a work flow such as:
>>> 
>>> docker run -v 389ds:/data 389ds/dirsrv:latest
>>> docker run -i -t -v 389ds:/data 389ds/tools:latest
>>> # shell inside of the tools container
>>> # dsconf 
>>> 
>>> -- Testing today:
>>> 
>>> To test the image as it exists today:
>>> 
>>> docker pull 
>>> registry.opensuse.org/home/firstyear/containers/389-ds-container:latest
>>> 
>>> 
>>> Thoughts and feedback?
>>> 
>>> If there are no objects, I'll push the rc to docker hub early next week 
>>> (2nd or 3rd of Sep)
>>> 
>>> --
>>> Sincerely,
>>> 
>>> William
>>> ___
>>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>>> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
>>> Fedora Code of Conduct: 
>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: 
>>> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
>> 
>> --
>> Sincerely,
>> 
>> William
>> ___
>> 389-devel mailing list -- 389-devel@lists.fedoraproject.org
>> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct: 
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: 
>> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
> 
> 
> 
> -- 
> Matúš Honěk
> Software 

Permission denied for relation pull_requests

[Jerry James]

What's this all about (seen after doing a git push to gap-pkg-hecke)?

$ git push
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (5/5), 690 bytes | 690.00 KiB/s, done.
Total 5 (delta 1), reused 0 (delta 0)
remote: Emitting a message to the fedmsg bus.
remote: * Publishing information for 1 commits
remote: Traceback (most recent call last):
remote:   File "/usr/lib/python2.7/site-packages/pagure/hooks/__init__.py",
line 394, in run_project_hooks
remote: changes=changes,
remote:   File "/usr/lib/python2.7/site-packages/pagure/hooks/__init__.py",
line 111, in runhook
remote: changes=changes,
remote:   File "/usr/lib/python2.7/site-packages/pagure/hooks/default.py",
line 421, in post_receive
remote: but_uids=pr_uids,
remote:   File "/usr/lib/python2.7/site-packages/celery/local.py",
line 191, in __call__
remote: return self._get_current_object()(*a, **kw)
remote:   File "/usr/lib/python2.7/site-packages/celery/app/task.py",
line 375, in __call__
remote: return self.run(*args, **kwargs)
remote:   File "/usr/lib/python2.7/site-packages/pagure/lib/tasks_utils.py",
line 36, in decorated_function
remote: return function(self, session, *args, **kwargs)
remote:   File "/usr/lib/python2.7/site-packages/pagure/lib/tasks.py",
line 696, in refresh_pr_cache
remote: session, project, but_uids=but_uids
remote:   File "/usr/lib/python2.7/site-packages/pagure/lib/query.py",
line 3411, in reset_status_pull_request
remote: {model.PullRequest.merge_status: None}, synchronize_session=False
remote:   File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/query.py",
line 2796, in update
remote: update_op.exec_()
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/persistence.py",
line 897, in exec_
remote: self._do_exec()
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/persistence.py",
line 995, in _do_exec
remote: update_stmt, params=self.query._params)
remote:   File "/usr/lib64/python2.7/site-packages/sqlalchemy/orm/session.py",
line 991, in execute
remote: bind, close_with_result=True).execute(clause, params or {})
remote:   File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py",
line 729, in execute
remote: return meth(self, multiparams, params)
remote:   File "/usr/lib64/python2.7/site-packages/sqlalchemy/sql/elements.py",
line 322, in _execute_on_connection
remote: return connection._execute_clauseelement(self, multiparams, params)
remote:   File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py",
line 826, in _execute_clauseelement
remote: compiled_sql, distilled_params
remote:   File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py",
line 958, in _execute_context
remote: context)
remote:   File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py",
line 1159, in _handle_dbapi_exception
remote: exc_info
remote:   File "/usr/lib64/python2.7/site-packages/sqlalchemy/util/compat.py",
line 199, in raise_from_cause
remote: reraise(type(exception), exception, tb=exc_tb)
remote:   File "/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py",
line 951, in _execute_context
remote: context)
remote:   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/default.py",
line 436, in do_execute
remote: cursor.execute(statement, parameters)
remote: ProgrammingError: (ProgrammingError) permission denied for
relation pull_requests
remote:  'UPDATE pull_requests SET merge_status=%(merge_status)s,
last_updated=%(last_updated)s WHERE pull_requests.project_id =
%(project_id_1)s AND pull_requests.status = %(status_1)s'
{'project_id_1': 37398, 'last_updated': datetime.datetime(2019, 9, 2,
22, 40, 2, 911501), 'merge_status': None, 'status_1': u'Open'}
remote: Sending to redis to log activity and send commit notification emails
remote: * Publishing information for 1 commits
To ssh://pkgs.fedoraproject.org/rpms/gap-pkg-hecke
   f942ae5..9356637  master -> master

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

Re: Sponsorship request

[Fabio Valentini]

On Mon, Sep 2, 2019 at 9:45 PM David Kaufmann  wrote:
>
> Hi!
>
> I'm looking for a sponsor to get rss2email back into fedora (it's
> orphaned and retired right now, as it's been FTBFS too long)
>
> I've already got the package reviewed (bug 1740389), but forgot the
> FE-NEEDSPONSOR dependency, so I'm looking for a sponsor via this list.
>
> Technically this is also a self-introduction, as I've never introduced
> myself on this list. I've been part of the fedora security team since
> sometime in 2015 and am subscribed to this list since sometime in 2016,
> but it was never necessary for me to maintain packages myself, and I
> didn't really participate in the discussions.
> I'm currently student and teach network security as study assistant.
> Next to that I'm working as a system administrator in a research group
> running almost exclusively fedora as operating system. :)
>
> Thanks,
> Astra
> (David Kaufmann)

Hi David,

Welcome (back) to fedora - at least officially ;)
It's nice to see another Austrian who works on fedora, too! (tough I'm
only working backwards from your e-mail address there)

I can't sponsor you since I'm not a member of the required account
group, but if you have other questions regarding the packaging
process, feel free to reach out.

Fabio

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

nbconvert 5.6.0

[Mukundan Ragavan]

I am unable to build nbconvert because of build failures. Can someone
please take a look at the build log and help me update this?

Build log - https://koji.fedoraproject.org/koji/taskinfo?taskID=37430133
Thanks,
Mukundan.



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

Re: inotify-tools with dead upstream cannot be fixed in Fedora

[Richard W.M. Jones]

On Sun, Sep 01, 2019 at 09:33:29PM +0200, Jan Kratochvil wrote:
> Hi,
> 
> Fix stack overflow in: `inotifytools_replace_filename`
> https://bugzilla.redhat.com/show_bug.cgi?id=1741472
> 
> Not sure how to fix this crashing bug. Upstream is dead while Fedora package
> maintainer requires to upstream the fix first. A Catch 22.
> 
> Debian has the crasher fixed by an off-trunk simple patch, Fedora cannot?

I would start by pulling in the Debian fix into the Fedora package.
Then talk to the Debian folk and see if you can set up a simple git
repo on one of the many free hosting services to collect these patches
"upstream".

Rich.

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

Re: Fedora Samba DC for what purpose it is released in Fedora ?

[Nico Kadel-Garcia]

On Mon, Sep 2, 2019 at 3:33 PM Alexander Bokovoy  wrote:
>
> On Mon, 02 Sep 2019, Dario Lesca wrote:
> >Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha scritto:
> >> I switched to run Samba DCs on a container with non Fedora / RHEL /
> >> CentOS provided RPMs.
> >
> >Thank Robert for reply.
> >
> >Then why don't release samba compiled with Heimdal kerberos?
> >
> >Just change a flag in build time, and all can use it into a production
> >environment.
> We do not support Heimdal builds in Fedora. It is not possible to reuse
> components of Samba built against Heimdal within other applications
> compiled against MIT Kerberos. This is, in particular, a show-stopper
> for FreeIPA and SSSD integration.

My personal experience is that this is not true. sssd in a recent
Fedora (Fedora 29 last year) works just fine against an honest-to-god
Samba 4.9 domain controller on RHEL 7. I've not tested tested it with
samba 4.11rc2 yeat, as I'm still working on that port. sssd also works
against a real AD controller. sssd does not rely on a freeipa server.
It has genuinely unfortunate behavior of pre-downloading the *entire*
LDAP tree, and breaking if it can't complete this, but that's another
issue that won't be visible in most small test environments with local
domain controllers.

Freeipa. I started setting up, realized it was going to take
months to replace existing structures and gain me *absolutely nothing*
compared to using the built-in AD or Samba systems already in my
network, and maybe tuning them slightly better.

> >If someone want test MIT version re-change the flag and rebuild it  by
> >himself .. or release also a samba suite with a specific name (es.
> >samba-mit-...).
> >
> >Samba DC is a useful solution in soma case, It is an inconvenience that
> >we must switch to another distro o use a third part repos  because this
> >suite into Fedora/RHEL/Centos is a experimental version
> You may create your own COPR repository and support your own build
> there. It is up to you to support that solution.

In the case of Samba, the support community is quite large. It's been
an active free software project, used worldwide and across multiple
operating systems, since the 1990's. I can vouch for that personally,
I published my first port of it for SunOS in roughly 1998. Nearly
every bulk storage device in the world uses it to provide CIFS
fileshares, many of those bulk storage devices with full domain
controller services available if not activated. It's one of the
cheapest ways to replace an AD domain controller.

FreeIPA does not have anywhere near the user and developer
community for servers. And sssd well, I've used it for Fedora and
RHEL, because it's a convenient wrapper for what I used to have to do
with the "net ads" command from Samba and is useful for admins who
can't be bothered to put more than one command in a shell script. But
its configurations are confusing, Do not get me *going* on the
interactions of sssd with the very limited "authconfig" command line
tool. And you really, really don't want to get me going on how sssd
insists on pre-loading *all* the upstream LDAP trees, works for 30
seconds and then crashes when the pre-load times out, and there is no
fix or way to restart *just that sssd LDAP sub-daemon*. The sssd damon
wrapping customized sssd subdamons, instead of simply using the
built-in system LDAP daemons is destabilizing and completely
unnecessary.

I'll take a Samba client in a heartbeat over the sssd mess in any even
slightly complex environment. And since the upstream for both sssd and
Samba clients can be the more popular and more supportable AD or Samba
server,  there has been little point to more than the most casual look
at a FreeIPA server.

Are there any significant sets of systems or clients reliant on
FreeIPA specific features? Because maintaining it does not seem worth
the developer effort if not client specifically requires it. I realize
it may be a big vendor project over at Red Hat, but does *anyone*  use
it out of a specific software need?

> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland

Sorry to chew on your employer, who are very helpful generally and
whose work I normally appreciate. sssd and freeipa have not been
examples of Red Hat's best work and community integration


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

Re: Unresponsive Maintainer: Chitlesh Goorah

[Geoffrey Marr]

Hi Alain,

Great to see there is some interest in the Electronics Lab Spin! Can you
reach out to Chitlesh and see if he is willing to give up his spot as the
maintainer of the group so that the spin can get the maintenance it needs?
If I don't hear from him in a week, I'll just continue through the
unresponsive maintainer process to get access. I would like to first start
by removing some packages that just don't work anymore, and add a few that
could greatly benefit this spin. I would welcome all of your help to get
this done as I am a software engineer by day, hardware hacker by night, so
input from someone who works with hardware on a daily basis would be
invaluable.

Geoff Marr
IRC: coremodule


On Mon, Sep 2, 2019 at 1:49 PM Alain Vigne  wrote:

> Hi Geoffrey
> I am Alain, FAS: avigne, a micro-electronic engineer, mainly interested in
> CAD/EDA tools.
> I started my journey to become a Fedora packager with this spin in mind (+
> introducing another PCB tool: pcb-rnd)
> I have been in contact with Chitlesh, and also with Kiara, who both
> stepped down the FEL effort.
>
> I volunteered to make things moving, but it was already an overwhelming
> task to package one new package, and at the time, had no idea how to handle
> a spin. Now, I am a bit more familiar with Fedora stuff, so I might be
> helpful there... ?
> I already proposed to co-maintain some packages, without success (I know
> now, I should file multiple tickets to claim the packages. Just didn't take
> the time for this bureaucracy).
> Some packages need updates, but some need a retirement, to be replaced
> with some other projects.
>
> What is your main concern with this spin?
> Can we team up to make this moving again?
> Who else has an interest in FEL?
>
> Best regards
> Alain
>
> On Mon, Sep 2, 2019 at 6:32 PM Geoffrey Marr  wrote:
>
>> Hi devel-list,
>>
>> I am trying to contact Chitlesh Goorah [0], as he is the maintainer of
>> the Fedora Electronics Lab Spin [1]. The spin desperately needs some love
>> and maintenance. Does anyone know how to contact him? I have reached out to
>> him three times in total, once in 2016, and again twice in 2019 and haven't
>> heard back. I have started the unresponsive maintainer process, here is a
>> link to the Bugzilla bug [2]. After a week of this mail being on the list,
>> I will open a FESCo ticket.
>>
>> Thanks,
>> Geoff Marr
>> IRC: coremodule
>>
>> [0] https://fedoraproject.org/wiki/User:Chitlesh
>> [1] https://fedoraproject.org/wiki/Electronic_Lab?rd=ElectronicLab_Spin
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1739872
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> Fedora Code of Conduct:
>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>>
>
>
> --
> Alain V.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Unresponsive Maintainer: Chitlesh Goorah

[Alain Vigne]

Hi Geoffrey
I am Alain, FAS: avigne, a micro-electronic engineer, mainly interested in
CAD/EDA tools.
I started my journey to become a Fedora packager with this spin in mind (+
introducing another PCB tool: pcb-rnd)
I have been in contact with Chitlesh, and also with Kiara, who both stepped
down the FEL effort.

I volunteered to make things moving, but it was already an overwhelming
task to package one new package, and at the time, had no idea how to handle
a spin. Now, I am a bit more familiar with Fedora stuff, so I might be
helpful there... ?
I already proposed to co-maintain some packages, without success (I know
now, I should file multiple tickets to claim the packages. Just didn't take
the time for this bureaucracy).
Some packages need updates, but some need a retirement, to be replaced with
some other projects.

What is your main concern with this spin?
Can we team up to make this moving again?
Who else has an interest in FEL?

Best regards
Alain

On Mon, Sep 2, 2019 at 6:32 PM Geoffrey Marr  wrote:

> Hi devel-list,
>
> I am trying to contact Chitlesh Goorah [0], as he is the maintainer of the
> Fedora Electronics Lab Spin [1]. The spin desperately needs some love and
> maintenance. Does anyone know how to contact him? I have reached out to him
> three times in total, once in 2016, and again twice in 2019 and haven't
> heard back. I have started the unresponsive maintainer process, here is a
> link to the Bugzilla bug [2]. After a week of this mail being on the list,
> I will open a FESCo ticket.
>
> Thanks,
> Geoff Marr
> IRC: coremodule
>
> [0] https://fedoraproject.org/wiki/User:Chitlesh
> [1] https://fedoraproject.org/wiki/Electronic_Lab?rd=ElectronicLab_Spin
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1739872
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>


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

Sponsorship request

[David Kaufmann]

Hi!

I'm looking for a sponsor to get rss2email back into fedora (it's
orphaned and retired right now, as it's been FTBFS too long)

I've already got the package reviewed (bug 1740389), but forgot the
FE-NEEDSPONSOR dependency, so I'm looking for a sponsor via this list.

Technically this is also a self-introduction, as I've never introduced
myself on this list. I've been part of the fedora security team since
sometime in 2015 and am subscribed to this list since sometime in 2016,
but it was never necessary for me to maintain packages myself, and I
didn't really participate in the discussions.
I'm currently student and teach network security as study assistant.
Next to that I'm working as a system administrator in a research group
running almost exclusively fedora as operating system. :)

Thanks,
Astra
(David Kaufmann)


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

[Bug 1748104] Please build perl-XML-SAX-Writer for EPEL-8

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Blocks||1748039




Referenced Bugs:

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

[Bug 1748039] Please build perl-Test-XML for EPEL 8

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 Depends On||1748104



--- Comment #1 from Paul Howarth  ---
Will need perl-XML-SAX-Writer first.


Referenced Bugs:

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

Re: Fedora Samba DC for what purpose it is released in Fedora ?

[Alexander Bokovoy]

On Mon, 02 Sep 2019, Nico Kadel-Garcia wrote:

On Mon, Sep 2, 2019 at 1:56 PM Alessio  wrote:


On Mon, Sep 2, 2019, 5:16 PM Dario Lesca  wrote:



After few minutes almost everything work well, except for a thing ...
all windows PC cannot access to others windows PC.



Wait. I'm not an expert. Said that, are we sure that the cause is krb MIT? Also 
on the samba ml it seems a supposition.
Windows PCs are all running windows7?
The same happens with windows 10?

And all these deprecated entries?

krb5kdc[6764](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), 
aes128-cts-hmac-sha1-96(17), DEPRECATED:arcfour-hmac(23), 
DEPRECATED:arcfour-hmac-exp(24), (-135), DEPRECATED:des-cbc-md5(3)})


As one of the people who backport current releases Samba to RHEL 7,
with the domain controller enabled, I can vouch that "yes, it's the
Kerberos". My work is over at https://github.com/nkadel/samba4repo,
and it seems to work fairly well with Fedora 30, though I've not
tested it as thoroughly. I have some test rigs in place for samba
4.11rc2 there.

The samba default values are all, by default, set as simply and
generally as possible. Activation of a real domain requires a good
deal of control and authority over local DNS, and the minimal setup
works really well for testers who don't need to start with all that
power and strenuous requirements.

II'd urge you to hop over to the samba-devel or samba mailing lists,
post your smb.conf and version of Samba, and look for debugging help
there.

As I said in the other response, we need bugs with debug logs and
network traces. Handwaving 'Windows PC cannot see Windows PC' does not
help us to help you to solve the problems you are seeing.

MIT Kerberos in Fedora 30 and rawhide did actively deprecate using of
weak crypto. RC4 is still accessible but system-wide crypto policy blocks its
use by default, so this might explain inability to authenticate with
NTLMSSP, for example (as opposed to use of AES ciphers). So there are
multiple factors that might affect use of Samba AD DC with MIT backend
on Fedora.





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


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

[Bug 1748104] New: Please build perl-XML-SAX-Writer for EPEL-8

[bugzilla]

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

Bug ID: 1748104
   Summary: Please build perl-XML-SAX-Writer for EPEL-8
   Product: Fedora EPEL
   Version: epel7
Status: NEW
 Component: perl-XML-SAX-Writer
  Assignee: andr...@bawue.net
  Reporter: p...@city-fan.org
QA Contact: extras...@fedoraproject.org
CC: andr...@bawue.net, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



There is a request to build perl-SOAP-Lite in EPEL 8 (Bug 1744683). It has a
build dependency on perl(Test::XML) (Bug 1748039), which in turn has a
dependency on perl-XML-SAX-Writer and its dependency
perl-XML-Filter-BufferText.

Please consider building perl-XML-SAX-Writer and perl-XML-Filter-BufferText in
EPEL 8. I have done test builds locally and they built successfully for me with
no further missing dependencies.

If you are too busy or uninterested in building packages for EPEL-8, I will be
happy to build them myself and can co-maintain if you wish.

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

Re: Fedora Samba DC for what purpose it is released in Fedora ?

[Alexander Bokovoy]

On Mon, 02 Sep 2019, Dario Lesca wrote:

Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha scritto:

I switched to run Samba DCs on a container with non Fedora / RHEL /
CentOS provided RPMs.


Thank Robert for reply.

Then why don't release samba compiled with Heimdal kerberos?

Just change a flag in build time, and all can use it into a production
environment.

We do not support Heimdal builds in Fedora. It is not possible to reuse
components of Samba built against Heimdal within other applications
compiled against MIT Kerberos. This is, in particular, a show-stopper
for FreeIPA and SSSD integration.



If someone want test MIT version re-change the flag and rebuild it  by
himself .. or release also a samba suite with a specific name (es.
samba-mit-...).

Samba DC is a useful solution in soma case, It is an inconvenience that
we must switch to another distro o use a third part repos  because this
suite into Fedora/RHEL/Centos is a experimental version

You may create your own COPR repository and support your own build
there. It is up to you to support that solution.

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

Re: Fedora Samba DC for what purpose it is released in Fedora ?

[Alexander Bokovoy]

On Mon, 02 Sep 2019, Dario Lesca wrote:

In Fedora Server there is a suit of package named samba and samba-dc*

These package, with some other, are useful to make Fedora an Active
Directory Domain Controller.

I have decide tu use it into a little lan and convert old samba NT 4
Style into AD-DC (classicupdate).

After few minutes almost everything work well, except for a thing ...
all windows PC cannot access to others windows PC.

I have ask on Samba ML some suggest, but in essence this was the
answer: "...Using MIT with a Samba AD DC is still experimental, you
should not run it in production..."
https://lists.samba.org/archive/samba/2019-September/225714.html

Then My questions now are:

a) For what purpose it's released Fedora Samba MIT-KERBEROS DC?


For testing purposes. There are few bits missing in MIT backend and we
are looking at fixing them at some point.


b) Someone can help me to debug my issue?


Please open a bug and provide more details, including debug logs and
network traces that demonstrate your problem.

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

Re: Fedora Samba DC for what purpose it is released in Fedora ?

[Nico Kadel-Garcia]

On Mon, Sep 2, 2019 at 1:56 PM Alessio  wrote:
>
> On Mon, Sep 2, 2019, 5:16 PM Dario Lesca  wrote:
>>
>>
>> After few minutes almost everything work well, except for a thing ...
>> all windows PC cannot access to others windows PC.
>
>
> Wait. I'm not an expert. Said that, are we sure that the cause is krb MIT? 
> Also on the samba ml it seems a supposition.
> Windows PCs are all running windows7?
> The same happens with windows 10?
>
> And all these deprecated entries?
>
> krb5kdc[6764](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), 
> aes128-cts-hmac-sha1-96(17), DEPRECATED:arcfour-hmac(23), 
> DEPRECATED:arcfour-hmac-exp(24), (-135), DEPRECATED:des-cbc-md5(3)})

As one of the people who backport current releases Samba to RHEL 7,
with the domain controller enabled, I can vouch that "yes, it's the
Kerberos". My work is over at https://github.com/nkadel/samba4repo,
and it seems to work fairly well with Fedora 30, though I've not
tested it as thoroughly. I have some test rigs in place for samba
4.11rc2 there.

The samba default values are all, by default, set as simply and
generally as possible. Activation of a real domain requires a good
deal of control and authority over local DNS, and the minimal setup
works really well for testers who don't need to start with all that
power and strenuous requirements.

II'd urge you to hop over to the samba-devel or samba mailing lists,
post your smb.conf and version of Samba, and look for debugging help
there.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Samba DC for what purpose it is released in Fedora ?

[Tomasz Torcz]

On Mon, Sep 02, 2019 at 05:14:35PM +0200, Dario Lesca wrote:
> a) For what purpose it's released Fedora Samba MIT-KERBEROS DC?

  This is for FreeIPA interoperability, described at
  https://www.freeipa.org/page/IPA_and_AD

  This is enabled because:
  1) FreeIPA is important part of Fedora deliverables
  2) Samba as DC is not.


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

Re: Fedora Samba DC for what purpose it is released in Fedora ?

[Alessio]

On Mon, Sep 2, 2019, 5:16 PM Dario Lesca  wrote:

>
> After few minutes almost everything work well, except for a thing ...
> all windows PC cannot access to others windows PC.
>

Wait. I'm not an expert. Said that, are we sure that the cause is krb MIT?
Also on the samba ml it seems a supposition.
Windows PCs are all running windows7?
The same happens with windows 10?

And all these deprecated entries?

krb5kdc[6764](info): AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18),
aes128-cts-hmac-sha1-96(17), DEPRECATED:arcfour-hmac(23),
DEPRECATED:arcfour-hmac-exp(24), (-135), DEPRECATED:des-cbc-md5(3)})

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

Re: [Test-Announce] Fedora 31 Beta Freeze

[Kevin Kofler]

Nicolas Mailhot via devel wrote:
> 2. However the IETF explicitely forbid it when defining the ISO 8501
> subset allowed on the Internet
> 
> RFC 3339> Although ISO 8601 permits the hour to be "24", this profile of
> ISO
> RFC 3339> 8601 only allows values between "00" and "23" for the hour in
> order
> RFC 3339> to reduce confusion.
> 
> Therefore, banning the 24:00 notation is necessary for interoperability,
> even if one does not agree with the IETF decision. (00:00 however is
> well-defined and not ambiguous)

IETF RFCs are only relevant for software. Humans need to comply only with 
ISO standards.

RFC 3339 specifically only claims to be about "representing and using date 
and time in Internet protocols", not on websites (which are just an 
arbitrary unformatted payload as far as the HTTPS protocol is concerned).

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

Re: [HEADS UP] Fedora 32 Python 3.8 rebuilds have started in a side tag

[Mat Booth]

On Fri, 23 Aug 2019 at 17:39, Miro Hrončok  wrote:

> On 23. 08. 19 17:15, Vít Ondruch wrote:
> >
> > Dne 23. 08. 19 v 17:05 Kaleb Keithley napsal(a):
> >>
> >>
> >> On Wed, Aug 21, 2019 at 1:23 PM Miro Hrončok  >> > wrote:
> >>
> >> On 15. 08. 19 0:18, Miro Hrončok wrote:
> >> > Hello, in order to deliver Python 3.8, we are running a
> coordinated
> >> rebuild in a
> >> > side tag.
> >> >
> >>
> >> The side tag was merged. Build in regular rawhide now. Thanks.
> >>
> >>
> >> /me wonders why my `dnf update`  on my f32/rawhide box isn't updating
> to
> >> python-3.8. Should it be?
> >
> >
> > I guess there was no Rawhide compose yet, which would contain the
> changes. I
> > would not be surprised if the merge broke the compose.
>
> We are monitoring it to firefight any such breakage, but the current
> breakage is
> not relevant to 3.8.
>
>
I noticed that eclipse-pydev stopped building with the introduction of
python 3.8. Can you offer any clue how to fix it?

Here is the log, you can see that the cython-based debugging extension when
built against python 3.8 is failing:
https://kojipkgs.fedoraproject.org//work/tasks/5618/37405618/build.log

As a workaround for now, I have disabled the python 3 extension and am
shipping only the python 2 extension for F32.

Any hints would be appreciated.

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

Unresponsive Maintainer: Chitlesh Goorah

[Geoffrey Marr]

Hi devel-list,

I am trying to contact Chitlesh Goorah [0], as he is the maintainer of the
Fedora Electronics Lab Spin [1]. The spin desperately needs some love and
maintenance. Does anyone know how to contact him? I have reached out to him
three times in total, once in 2016, and again twice in 2019 and haven't
heard back. I have started the unresponsive maintainer process, here is a
link to the Bugzilla bug [2]. After a week of this mail being on the list,
I will open a FESCo ticket.

Thanks,
Geoff Marr
IRC: coremodule

[0] https://fedoraproject.org/wiki/User:Chitlesh
[1] https://fedoraproject.org/wiki/Electronic_Lab?rd=ElectronicLab_Spin
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1739872
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1744678] [RFE] Can perl-Linux-Pid be branched for EPEL8

[bugzilla]

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

Xavier Bachelot  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED



--- Comment #1 from Xavier Bachelot  ---
epel8 branch requested, I will build when it's created.

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

Re: Fedora Samba DC for what purpose it is released in Fedora ?

[Robert Marcano]

On 9/2/19 11:58 AM, Dario Lesca wrote:

Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha scritto:

I switched to run Samba DCs on a container with non Fedora / RHEL /
CentOS provided RPMs.


Thank Robert for reply.

Then why don't release samba compiled with Heimdal kerberos?


I was told that some non DC usages of Samba are affected, The MIT 
configuration files will not apply for example. That will change how 
people currently use Samba as a non DC server, for example as a member 
server.




Just change a flag in build time, and all can use it into a production
environment.

If someone want test MIT version re-change the flag and rebuild it  by
himself .. or release also a samba suite with a specific name (es.
samba-mit-...).

Samba DC is a useful solution in soma case, It is an inconvenience that
we must switch to another distro o use a third part repos  because this
suite into Fedora/RHEL/Centos is a experimental version

Thanks


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

Re: Fedora Samba DC for what purpose it is released in Fedora ?

[Dario Lesca]

Il giorno lun, 02/09/2019 alle 11.26 -0400, Robert Marcano ha scritto:
> I switched to run Samba DCs on a container with non Fedora / RHEL / 
> CentOS provided RPMs.

Thank Robert for reply.

Then why don't release samba compiled with Heimdal kerberos?

Just change a flag in build time, and all can use it into a production
environment.

If someone want test MIT version re-change the flag and rebuild it  by
himself .. or release also a samba suite with a specific name (es.
samba-mit-...).

Samba DC is a useful solution in soma case, It is an inconvenience that
we must switch to another distro o use a third part repos  because this
suite into Fedora/RHEL/Centos is a experimental version

Thanks

-- 
Dario Lesca
(inviato dal mio Linux Fedora 30 Workstation)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora Workstation and disabled by default firewall

[Sheogorath via devel]

On 8/28/19 1:01 AM, Adam Williamson wrote:
> On Tue, 2019-08-27 at 15:06 +0200, Jiri Eischmann wrote:
>> mcatanz...@gnome.org píše v Út 27. 08. 2019 v 15:07 +0300:
>>> On Tue, Aug 27, 2019 at 4:22 AM, John Harris 
>>> wrote:
 No, that is not how this works, at all. First, let's go ahead and
 address the 
 idea that "if the firewall blocks it, the app breaks, so it's the
 firewall's 
 fault": It's not. If the firewall has not been opened, that just
 means it 
 can't be accessed by remote systems until you EXPLICITLY open that
 port, with 
 the correct protocol, on your firewall. That's FINE. That's how
 it's designed 
 to work. There's nothing wrong with that.

 This means that the system administrator (or owner, if this is
 some 
 individual's personal system) must allow the port to be accessed
 remotely, 
 before the app can be reached remotely, increasing the security of
 the system.
>>>
>>> You've already lost me here. Sorry, but we do not and will not
>>> install a firewall GUI that exposes complex technical details like
>>> port numbers. Expecting users to edit firewall rules to use their
>>> apps is ridiculous and I'm not really interested in debating it.
>>
>> Yeah, when you ask users questions they're not qualified to answer,
>> you're just creating bad design.
>> I always imagine my mom (who BTW has been a Fedora user for years) how
>> she'd deal with that and I can't really imagine her opening/closing
>> firewall ports. She'd be puzzled even by "Do you trust this network?"
>> and would probably just click "Yes" to make it go away. No additional
>> security, just annoying UX.
> 
> However, Fedora Workstation is an edition. Which means it has a
> *policy-defined* target audience. That target audience is defined here:
> https://fedoraproject.org/wiki/Workstation/Workstation_PRD#Target_Audience
> 
> Case 1: "Engineering/CS student"
> Case 2: "Independent Developer"
> Case 3: "Small Company Developer"
> Case 4: "Developer in a Large Organization"
> 
> Are those people we believe do not understand the concepts associated
> with firewalls?
> 

Let's get real. It doesn't matter if you understand firewalls or not.
Reality is that developers run applications they are working on in
development configurations on their local system. With some luck they
are properly configured but as far as I know most dev setups, they are
not considered secure or "production-ready" and that for good reasons.

But what do we do after a long day? We take our notebook and close the
lid at the end of a long day or when we head over to this annoying
meeting with the new customer. We probably don't close and shut down all
services we are developing/testing in background. Then we head over
there, open the notebook and of course need some kind of
presentation/picture/data we stored on the cloud storage provider of our
trust. We connect to the public/unknown WiFi and *boom* suddenly we have
unexpected open ports on a public network we didn't to expose them to.

This is not something that people do on purpose but it simply happens.
It's how we use devices nowadays.

So I guess it would already improve the situation when we would only
open the ports on install, which by far isn't a perfect solution but
would already prevent the scenario mentioned above. Which appears no
matter if someone is aware of firewall concepts or not.

Let's work on solving this problem for everyone, because it's a general
problem.

-- 
Signed
Sheogorath



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

Re: Fedora Samba DC for what purpose it is released in Fedora ?

[Robert Marcano]

On 9/2/19 11:14 AM, Dario Lesca wrote:

In Fedora Server there is a suit of package named samba and samba-dc*

These package, with some other, are useful to make Fedora an Active
Directory Domain Controller.

I have decide tu use it into a little lan and convert old samba NT 4
Style into AD-DC (classicupdate).

After few minutes almost everything work well, except for a thing ...
all windows PC cannot access to others windows PC.

I have ask on Samba ML some suggest, but in essence this was the
answer: "...Using MIT with a Samba AD DC is still experimental, you
should not run it in production..."
https://lists.samba.org/archive/samba/2019-September/225714.html

Then My questions now are:

a) For what purpose it's released Fedora Samba MIT-KERBEROS DC?


I think it is only for testing, I think Red Hat team isn't working too 
much on bringing full DC support to Samba, only what is needed for IPA / 
Windows Domains compatibility, but this is my guess.


Testing and helping upstream with the MIT Kerberos is the only option, 
unless enabling Heimdal is possible.



b) Someone can help me to debug my issue?


That was one of the issues I got when testing the Fedora Samba DC build, 
another one was https://bugzilla.samba.org/show_bug.cgi?id=13516 and 
https://bugzilla.samba.org/show_bug.cgi?id=11362


I switched to run Samba DCs on a container with non Fedora / RHEL / 
CentOS provided RPMs. It is the only current option if you want to use 
it on production.




Many thanks


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

Fedora Samba DC for what purpose it is released in Fedora ?

[Dario Lesca]

In Fedora Server there is a suit of package named samba and samba-dc*

These package, with some other, are useful to make Fedora an Active
Directory Domain Controller.

I have decide tu use it into a little lan and convert old samba NT 4
Style into AD-DC (classicupdate).

After few minutes almost everything work well, except for a thing ...
all windows PC cannot access to others windows PC.

I have ask on Samba ML some suggest, but in essence this was the
answer: "...Using MIT with a Samba AD DC is still experimental, you 
should not run it in production..."
https://lists.samba.org/archive/samba/2019-September/225714.html

Then My questions now are:

a) For what purpose it's released Fedora Samba MIT-KERBEROS DC?
b) Someone can help me to debug my issue?

Many thanks

-- 
Dario Lesca
(inviato dal mio Linux Fedora 30 Workstation)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[Bug 1748057] New: Request for branching to epel-8

[bugzilla]

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

Bug ID: 1748057
   Summary: Request for branching to epel-8
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-LDAP
  Assignee: jples...@redhat.com
  Reporter: maximilian.phili...@saltation.com
QA Contact: extras...@fedoraproject.org
CC: caillon+fedoraproj...@gmail.com, caol...@redhat.com,
john.j5l...@gmail.com, jples...@redhat.com,
ka...@ucw.cz, perl-devel@lists.fedoraproject.org,
rhug...@redhat.com, rstr...@redhat.com,
sandm...@redhat.com
  Target Milestone: ---
Classification: Fedora



hi,
perl-LDAP used to be part of @base in RHEL 6 & 7, but is completely missing
from 8. I would therefore like to request the inclusion of perl-LDAP in epel8. 
It is fairly important for any ldap related perl scripts..


There is no perl-LDAP component in Fedora EPEL, according to Petr Pisar I am
supposed to report this here.

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

Re: f32/rawhide, nothing provides module(platform:f31)

[Miroslav Suchý]

Dne 02. 09. 19 v 14:25 Petr Pisar napsal(a):
> The point is that the one who designed these rules forgot that people
> will want to upgrade from an unsupported stream to a supportrf one. And
> that the upgrade should be silent and automatic for cases when a user

Negative sir.
As I stated the change is documented here:
  
https://docs.fedoraproject.org/en-US/modularity/making-modules/managing-defaults/#_setting_or_changing_a_default
It is just, that it is first time it happened - Already tracked as:
  https://bugzilla.redhat.com/show_bug.cgi?id=1747408

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: libexempi SONAME bump in rawhide

[Debarshi Ray]

On Mon, Sep 02, 2019 at 04:08:03PM +0200, Nikola Forr? wrote:
> On Fri, 2019-08-30 at 20:09 +, Debarshi Ray wrote:
> > Were you looking for a go ahead to rebuild the affected packages in
> > Fedora proper? In that case, you have my whole hearted appreciation
> > for taking care of the eog and tracker-miners rebuilds. :)
> 
> I would like to do that, but it would require help of a provenpackager,
> since I'm not one myself.

You could apply to become a provenpackager:
https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/

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

Fedora 31 compose report: 20190902.n.0 changes

[Fedora Branched Report]

OLD: Fedora-31-20190901.n.0
NEW: Fedora-31-20190902.n.0

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

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

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

= ADDED IMAGES =
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-31-20190902.n.0.iso

= DROPPED IMAGES =
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-31-20190901.n.0.iso

= ADDED PACKAGES =
Package: icewm-1.3.8-16.fc29
Summary: Light and configurable window manager
RPMs:icewm icewm-clearlooks icewm-gnome icewm-xdgmenu
Size:4.88 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =

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

Re: Fedora Workstation and disabled by default firewall

[Sheogorath via devel]

On 8/27/19 3:25 AM, John Harris wrote:
> On Monday, August 26, 2019 7:25:27 AM MST Iñaki Ucar wrote:
>> On Mon, 26 Aug 2019 at 15:25, Robert Marcano 
>> wrote:
>>>
>>>
>>> On 8/26/19 9:07 AM, mcatanz...@gnome.org wrote:
>>>


 Well the thing is, blocknig ports tends to break applications that want
 to use those ports. We're not going to do that, period. It also doesn't
 really accomplish anything: either your app or service needs network
 access and you have whitelisted it (in which case the firewall provides
 no security), or it needs network access and you have not whitelisted
 it
 (in which case your firewall breaks your app/service). In no case does
 it increase your security without breaking your app, right? Unless you
 have malware installed (in which case, you have bigger problems than
 the
 firewall). Or unless you have a vulnerable network service installed
 that you don't want (in which case, uninstall it).
>>>
>>>
>>>
>>> This is a reasonable point of view, until you notice Linux desktops
>>> evironments don't provide applications with a method to detect if they
>>> are running on a private network or not (See Windows Home, Office,
>>> Internet network settings).
>>
>>
>> That's a very good point. When Windows connects to a new network, it
>> asks whether it's a home connection (and then you want to share
>> resources in the network) or it's a public connection (and everything
>> should stay private). And I think that, if the user simply ignores the
>> notification, the default is to consider it a public network (not 100%
>> sure though). That's a good policy I think, and it would be great if
>> NetworkManager could do that.
>>
>> I understand mcatanzaro's point of view, but it's quite narrow,
>> because laptops not only connect to home networks to share resources,
>> but also to many insecure public WiFis. I don't think we should rely
>> on chasing upstream developers to behave in a *possibly* insecure
>> environment. The system should abstract this for them and set proper
>> firewall rules.
> 
> Keep in mind that even Windows doesn't address the use case where you set it 
> to Home or Business, or whatever the private setting is, and then plug in a 
> connection to a public network. It thinks it's still the same.
> 

I had something back in mind that tickled, when I read this. Because I
remember that Windows 7 did something with the default Gateway mac
address, so I did some digging.

https://web.archive.org/web/20170405202217/https://blogs.technet.microsoft.com/networking/2010/09/08/network-location-awareness-nla-and-how-it-relates-to-windows-firewall-profiles/

There is quite some documentation about how Windows
determines/determined when it was connected to a different network
(being it by wire or WiFi). Even when this information is might outdated
when looking at Windows 10.

Hope that helps to provide some inspiration towards solving this problem
and create better Firewall rule sets :)

(But in general it sounds like something that should go into
NetworkManager and could be useful for easier network profiles)

-- 
Signed
Sheogorath



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

[Bug 1748039] Please build perl-Test-XML for EPEL 8

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

 Blocks||1744683




Referenced Bugs:

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

[Bug 1744683] [RFE] EPEL8 branch for perl-SOAP-Lite

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

 Depends On||1748037, 1748038, 1748039



--- Comment #3 from Jan Pazdziora  ---
I've filed bugzillas for the remaining build dependencies now.


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1748037
[Bug 1748037] Please build perl-MIME-Lite for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1748038
[Bug 1748038] Please build perl-XML-Parser-Lite for EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1748039
[Bug 1748039] Please build perl-Test-XML for EPEL 8
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org

[Bug 1748038] Please build perl-XML-Parser-Lite for EPEL 8

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

 Blocks||1744683




Referenced Bugs:

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

[Bug 1748038] New: Please build perl-XML-Parser-Lite for EPEL 8

[bugzilla]

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

Bug ID: 1748038
   Summary: Please build perl-XML-Parser-Lite for EPEL 8
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-XML-Parser-Lite
  Assignee: jples...@redhat.com
  Reporter: jpazdzi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Description of problem:

We have a request to build perl-SOAP-Lite in EPEL 8, bug 1744683. It has a
build dependency on perl(XML::Parser::Lite). Please consider building
perl-XML-Parser-Lite in EPEL 8.

Steps to Reproduce:
1. Search for package providing perl(XML::Parser::Lite) in EPEL 8.

Actual results:

No perl-XML-Parser-Lite in EPEL 8.

Expected results:

perl-XML-Parser-Lite-0.722-4.el8 in EPEL 8.

Additional info:

Please let me know if you are not interested in maintaining the package on EPEL
8.

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

[Bug 1748039] New: Please build perl-Test-XML for EPEL 8

[bugzilla]

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

Bug ID: 1748039
   Summary: Please build perl-Test-XML for EPEL 8
   Product: Fedora EPEL
   Version: epel8
Status: NEW
 Component: perl-Test-XML
  Assignee: p...@city-fan.org
  Reporter: jpazdzi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Description of problem:

We have a request to build perl-SOAP-Lite in EPEL 8, bug 1744683. It has a
build dependency on perl(Test::XML). Please consider building perl-Test-XML in
EPEL 8.

Steps to Reproduce:
1. Search for package providing perl(Test::XML) in EPEL 8.

Actual results:

No perl-Test-XML in EPEL 8.

Expected results:

perl-Test-XML-0.08-15.el8 in EPEL 8.

Additional info:

Please let me know if you are not interested in maintaining the package on EPEL
8.

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

Re: libexempi SONAME bump in rawhide

[Nikola Forró]

On Fri, 2019-08-30 at 20:09 +, Debarshi Ray wrote:
> Thanks for the heads-up!
> 
> Were you looking for a go ahead to rebuild the affected packages in
> Fedora proper? In that case, you have my whole hearted appreciation
> for taking care of the eog and tracker-miners rebuilds. :)

I would like to do that, but it would require help of a provenpackager,
since I'm not one myself.

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

[Bug 1744683] [RFE] EPEL8 branch for perl-SOAP-Lite

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

 Depends On||1744711




Referenced Bugs:

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

[Bug 1744711] [RFE] EPEL8 branch of perl-IO-SessionData

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

 Blocks||1744683




Referenced Bugs:

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

[Bug 1744361] Please build perl-MIME-tools for EPEL 8

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

 Blocks||1744683




Referenced Bugs:

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

[Bug 1744683] [RFE] EPEL8 branch for perl-SOAP-Lite

[bugzilla]

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

Jan Pazdziora  changed:

   What|Removed |Added

 Depends On||1744361



--- Comment #2 from Jan Pazdziora  ---
perl-MIME-tools-5.509-9.el8 with 'perl(MIME::Parser)' is in EPEL 8 testing


Referenced Bugs:

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

[Bug 1747726] perl-Git-Repository-1.324 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-2019-21d1a12ca6 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-21d1a12ca6

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

Fedora-31-20190902.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 31/142 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-31-20190901.n.0):

ID: 440045  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/440045
ID: 440047  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/440047
ID: 440048  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/440048
ID: 440049  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/440049
ID: 440058  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/440058
ID: 440100  Test: x86_64 KDE-live-iso base_update_cli
URL: https://openqa.fedoraproject.org/tests/440100
ID: 440102  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/440102
ID: 440140  Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/440140
ID: 440142  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/440142
ID: 440161  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/440161
ID: 440164  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/440164
ID: 440165  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/440165
ID: 440168  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/440168
ID: 440175  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/440175
ID: 440177  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/440177
ID: 440179  Test: x86_64 universal install_kickstart_nfs
URL: https://openqa.fedoraproject.org/tests/440179
ID: 440180  Test: x86_64 universal install_pxeboot
URL: https://openqa.fedoraproject.org/tests/440180
ID: 440182  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/440182

Old failures (same test failed in Fedora-31-20190901.n.0):

ID: 440070  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/440070
ID: 440078  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/440078
ID: 440080  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/440080
ID: 440105  Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/440105
ID: 440108  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/440108
ID: 440129  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/440129
ID: 440136  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/440136
ID: 440162  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/440162
ID: 440167  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/440167
ID: 440171  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/440171
ID: 440172  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/440172
ID: 440173  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/440173
ID: 440176  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/440176
ID: 440181  Test: x86_64 universal install_pxeboot@uefi
URL: https://openqa.fedoraproject.org/tests/440181

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

Old soft failures (same test soft failed in Fedora-31-20190901.n.0):

ID: 440166  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/440166

Passed openQA tests: 98/142 (x86_64)

New passes (same test not passed in Fedora-31-20190901.n.0):

ID: 440107  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/440107

Skipped non-gating openQA tests: 13 of 144

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
System load changed from 1.50 to 0.55
Previous test data: https://openqa.fedoraproject.org/tests/439620#downloads
Current test data: https://openqa.fedoraproject.org/tests/440093#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
System load changed from 0.99 to 0.44
Previous test data: https://openqa.fedoraproject.org/tests/439622#downloads
Current test data: 

Re: Is Modularity (MBS) dead?

[Petr Pisar]

On 2019-09-01, Igor Gnatenko  wrote:
> Being one of the biggest users of Modularity (more than 25 modules)
> I'm surprised that:
>
> 1) Many builds are stuck for more than half a month
> (https://mbs.fedoraproject.org/module-build-service/1/module-builds/5639,
> 13 Aug)

Simply resubmit the build. Once it stoppes moving, bump a modulemd
and start a new build. That allowed me to come around my perl modules.

I experienced similar stalls even before and was told that "these are
rare race conditions".

> 2) F32 branching was not handled well, basically all Rust modules
> can't be built due to wrong way of branching
> (https://pagure.io/releng/issue/8718)

From the ticket: "All rust modules haven't been built for F32 because
rust:stable has circular dependency."

Modalarity cannot inherit old builds onto new platforms. Hence cycles
cannot be circumvented by injecting a build from a different platform.
(Actually you can make a build installable on all platforms:
build-require one platform, run-require all; Java SIG uses it.) Thus
with the current modularity cycles are a no-go. I recommend you creating
a series of bootstrapping modules that will lead to a current rust
without cycles.

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

[Bug 1747170] perl-Date-Manip-6.78 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2019-9ff6198c59 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-9ff6198c59

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

Re: f32/rawhide, nothing provides module(platform:f31)

[Petr Pisar]

On 2019-09-02, Igor Gnatenko  wrote:
> Whatever you set in the defaults, DNF ignores that on the update.
>
> https://pagure.io/releng/fedora-module-defaults/blob/master/f/libgit2.yaml
> https://pagure.io/releng/fedora-module-defaults/blob/f31/f/libgit2.yaml
>
It's not that DNF was ignoring defaults.

When a package from a default stream is going to be installed, DNF
enables that stream. Hence when performing an upgrade, the original
default stream has already been enabled. And switching enabled streams
is not allowed.

The point is that the one who designed these rules forgot that people
will want to upgrade from an unsupported stream to a supportrf one. And
that the upgrade should be silent and automatic for cases when a user
did not explicitly enabled a stream. And that the upgrade should be
possible and easy for cases when the user did explicitly enabled the
stream.

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

Re: Intention to retire Release Notes RPM

[Brian (bex) Exelbierd]

Closing the loop: This package has been retired via `fedpkg retire` in f31
and rawhide.

regards,

bex

On Thu, Aug 1, 2019 at 10:43 PM Brian (bex) Exelbierd 
wrote:

> Hi All,
>
> Barring objection, I plan to retire the release notes package from
> Fedora on or after August 9, 2019.  The package has not been updated
> since F28.  Despite the fact that we have literally shipped a package
> containing the F28 release notes in F29 and F30, there have been no
> comments.  This has been discussed with the docs team and is
> supported.  I am not aware of any dependencies and I believe it was
> removed from release criteria in F29.
>
> I will run `fedpkg retire` and further request removal via
>
> https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=rawhide=fedora-obsolete-packages
>
> Please reply on list if you have any questions or concerns.
>
> regards,
>
> bex
> --
> Brian "bex" Exelbierd (he/him/his)
> Fedora Community Action & Impact Coordinator
> @bexelbie | http://www.winglemeyer.org
> bexel...@redhat.com | b...@pobox.com
>


-- 
Brian "bex" Exelbierd (he/him/his)
Fedora Community Action & Impact Coordinator
@bexelbie | http://www.winglemeyer.org
bexel...@redhat.com | b...@pobox.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: swap on ZRAM, zswap, and Rust was: Better interactivity in low-memory situations

[Martin Kolman]

- Original Message -
> From: "Chris Murphy" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Friday, August 30, 2019 9:55:52 PM
> Subject: swap on ZRAM, zswap, and Rust was: Better interactivity in 
> low-memory situations
> 
> Hi,
> This is yet another follow-up for this thread:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XUZLHJ5O32OX24LG44R7UZ2TMN6NY47N/
> 
> 
> Basics:
> "zswap" compresses swap and uses a defined memory pool as a cache,
> with spill over (still compressed) going into a conventional swap
> partition. The memory pool doesn't appear as a separate block device.
> A conventional swap partition on a drive is required.
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/blockdev/zram.txt?h=v5.2.9
> 
> "swap on ZRAM" A ZRAM device appears as a block device, and is
> effectively a compressed RAM disk. It's common for this to be the
> exclusive swap device, of course it is volatile so in that
> configuration your system can't hibernate. But it's also possible to
> use swap priority in fstab to cause the ZRAM device to be used with
> higher priority, and a conventional swap partition on a drive with a
> lower priority.
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/vm/zswap.rst?h=v5.2.9

Just a slight addition to this comparison - AFAIK there is a slight difference 
in how zswap and zram handle the
in-ram swap device being full & making use of the swap device on harddrive.

If the zswap device becomes full, zswap will, according to the docs, free up 
spase in RAM by moving the least recently used
pages to the disk, so that the "hot" pages stay in ram & new pages can be 
placed there.

In comparison AFAIK, there is no such mechanism for zram and the priority value 
simply means which swap will be used as the first
one and once it becomes full, new pages will simply go to the next swap with 
lower priority. Please correct me if I am completely
wrong and the Linux swap allocation algorithm actually moves pages between swap 
devices based on priority. :)

> 
> 
> What they do:
> Either strategy can help avoid swap thrashing, by moderating the
> transition from exclusively RAM based work, to heavy swapping on disk.
> In my testing, the most aggressive memory starved workloads still
> result in an unresponsive system. Neither are a complete solution,
> they really seem to just be moderators that kick the can down the
> road. But I do think it's an improvement especially in the incidental
> swap use case, where transition from memory to swap isn't noticeable.
> 
> 
> Which is better?
> I don't know. Seriously, that's what all of my testing as come down
> to. A user won't likely notice the difference. Both dynamically
> allocate memory to their "memory pools" on demand. But otherwise, they
> really are two very different implementations. Regardless, Fedora
> Workstation and probably even Fedora Server, should use one of them by
> default out of the box.
> 
> IoT folks are already using swap on ZRAM by default, in lieu of a disk
> based swap partition. And Anaconda folks are doing the same for low
> memory devices when the installer is launched. I've been using zswap
> on Fedora Workstation edition on my laptop, and Fedora Server on an
> Intel NUC, for maybe two years (earlier this summer I switched both of
> them swap on ZRAM to compare).
> 
> How are they different?
> There are several "swap on ZRAM" implementations. The zram package in
> Fedora right now is what IoT folks are using which installs a systemd
> service unit to setup the ZRAM block device, mkswap on it, and then
> swapon, during system startup. Simple.
> 
> The ideal scenario is to get everyone on the same page, and so far it
> looks like systemd's zram-generator, built in Rust, meets all the
> requirements. That needs to be confirmed, but also right now there's a
> small problem, it's not working. So we kinda need a someone familiar
> with Rust and systemd to take this on, if we want to use the same
> thing everywhere.
> https://github.com/systemd/zram-generator/issues/4
> 
> Whereas zswap is setup by using boot parameters, which we could have
> the installer set, contingent on a conventional swap partition being
> created.
> zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=20
> zswap.zpool=zbud
> 
> Zswap upstream tells me they're close to dropping the experimental
> status, hopefully by the end of the summer. It might be a bit longer
> before they're as confident with zpool type z3fold.
Indeed, I've had issues with stability in the past when I tried the z3fold
option, but no issue with the default values in the last ~year, so it
really seems to be ready with the default values. 

> 
> Hackfest anyone?
> 
> 
> 
> --
> Chris Murphy
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to 

Fedora rawhide compose report: 20190902.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20190901.n.0
NEW: Fedora-Rawhide-20190902.n.0

= SUMMARY =
Added images:0
Dropped images:  1
Added packages:  12
Dropped packages:0
Upgraded packages:   54
Downgraded packages: 0

Size of added packages:  99.59 MiB
Size of dropped packages:0 B
Size of upgraded packages:   964.05 MiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20190901.n.0.iso

= ADDED PACKAGES =
Package: golang-github-mmcloughlin-geohash-0.9.0-1.fc32
Summary: Golang geohash library
RPMs:golang-github-mmcloughlin-geohash-devel
Size:316.97 KiB

Package: golang-github-nrdcg-namesilo-0.2.1-1.fc32
Summary: Go library for accessing the Namesilo API
RPMs:golang-github-nrdcg-namesilo-devel
Size:25.53 KiB

Package: icewm-1.6.1-4.fc32
Summary: Window manager designed for speed, usability, and consistency
RPMs:icewm icewm-data icewm-fonts-settings icewm-minimal-session 
icewm-themes icewm-wallpaper
Size:22.15 MiB

Package: mako-1.4-1.module_f32+6140+eb754d2b
Summary: Lightweight Wayland notification daemon
RPMs:mako
Size:253.46 KiB

Package: rofi-1.5.4-1.module_f32+6140+eb754d2b
Summary: A window switcher, application launcher and dmenu replacement
RPMs:rofi rofi-devel rofi-devel-doc rofi-themes
Size:49.34 MiB

Package: rust-srpm-macros-10-2.module_f32+6151+ad6fc8e1
Summary: RPM macros for building Rust source packages
RPMs:rust-srpm-macros
Size:9.42 KiB

Package: sway-1.2-1.module_f32+6140+eb754d2b
Summary: i3-compatible window manager for Wayland
RPMs:sway
Size:25.17 MiB

Package: swaybg-1.0-2.module_f32+6140+eb754d2b
Summary: Wallpaper tool for Wayland compositors
RPMs:swaybg
Size:117.26 KiB

Package: swayidle-1.5-2.module_f32+6140+eb754d2b
Summary: An idle daemon for wayland compositors
RPMs:swayidle
Size:110.97 KiB

Package: swaylock-1.4-2.module_f32+6140+eb754d2b
Summary: Screen locker for Wayland
RPMs:swaylock
Size:201.57 KiB

Package: wayland-protocols-1.18-1.module_f32+6140+eb754d2b
Summary: Wayland protocols that adds functionality not available in the core 
protocol
RPMs:wayland-protocols-devel
Size:73.21 KiB

Package: wlroots-0.7.0-1.module_f32+6140+eb754d2b
Summary: A modular Wayland compositor library
RPMs:wlroots wlroots-devel
Size:1.85 MiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  Zim-0.72.0-1.fc32
Old package:  Zim-0.71.1-3.fc32
Summary:  Desktop wiki & notekeeper
RPMs: Zim
Size: 1.69 MiB
Size change:  5.14 KiB
Changelog:
  * Sun Sep 01 2019 Robin Lee  - 0.72.0-1
  - Release 0.72.0
  - Add launchable entry to metainfo (RHBZ#1729275)


Package:  dino-0.0-0.12.20190830.git.016ab2c.fc32
Old package:  dino-0.0-0.10.20190601.git.8120203.fc31
Summary:  Modern XMPP ("Jabber") Chat Client using GTK+/Vala
RPMs: dino dino-devel
Size: 5.94 MiB
Size change:  811.76 KiB
Changelog:
  * Wed Jul 24 2019 Fedora Release Engineering  - 
0.0-0.11.20190601.git.8120203
  - Rebuilt for https://fedoraproject.org/wiki/Fedora_31_Mass_Rebuild

  * Sat Aug 31 2019 Randy Barlow  - 
0.0-0.12.20190830.git.016ab2c1
  - Update to 016ab2c1.
  - Fix FTBFS (#1735087).
  - https://github.com/dino/dino/compare/8120203d...016ab2c1


Package:  domoticz-4.10718-0.git20190831.1.fc32
Old package:  domoticz-4.9700-7.fc31
Summary:  Open source Home Automation System
RPMs: domoticz
Size: 47.32 MiB
Size change:  1.37 MiB
Changelog:
  * Sat Aug 31 2019 Michael Cronenworth  - 
4.10718-0.git20190831.1
  - Version update to current master git checkout
  - Compile against OpenZWave 1.6


Package:  erlang-22.0.7-1.fc32
Old package:  erlang-21.3.8.6-2.fc31
Summary:  General-purpose programming language and runtime environment
RPMs: erlang erlang-asn1 erlang-common_test erlang-compiler 
erlang-crypto erlang-debugger erlang-dialyzer erlang-diameter erlang-doc 
erlang-edoc erlang-eldap erlang-erl_docgen erlang-erl_interface erlang-erts 
erlang-et erlang-eunit erlang-examples erlang-ftp erlang-hipe erlang-inets 
erlang-jinterface erlang-kernel erlang-megaco erlang-mnesia erlang-observer 
erlang-odbc erlang-os_mon erlang-parsetools erlang-public_key erlang-reltool 
erlang-runtime_tools erlang-sasl erlang-snmp erlang-ssh erlang-ssl 
erlang-stdlib erlang-syntax_tools erlang-tftp erlang-tools erlang-wx 
erlang-xmerl
Dropped RPMs: erlang-otp_mibs
Size: 182.89 MiB
Size change:  1.86 MiB
Changelog:
  * Tue Jul 30 2019 Peter Lemenkov  - 22.0.7-1
  - Ver. 22.0.7
  - Removed otp_mibs application


Package:  fuse3-3.6.2-1.fc32
Old package:  fuse3-3.6.1-4.fc31
Summary:  File System in Userspace (FUSE) v3 utilities
RPMs: fuse-common fuse3 fuse3-devel f

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

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
10 of 45 required tests failed, 6 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all
MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default
MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default

Failed openQA tests: 26/142 (x86_64), 1/2 (arm)

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

ID: 439859  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/439859
ID: 439860  Test: x86_64 KDE-live-iso desktop_notifications_postinstall
URL: https://openqa.fedoraproject.org/tests/439860

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

ID: 439794  Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/439794
ID: 439795  Test: x86_64 Server-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/439795
ID: 439812  Test: x86_64 Server-dvd-iso 
server_role_deploy_domain_controller **GATING**
URL: https://openqa.fedoraproject.org/tests/439812
ID: 439813  Test: x86_64 Server-dvd-iso server_freeipa_replication_master
URL: https://openqa.fedoraproject.org/tests/439813
ID: 439814  Test: x86_64 Server-dvd-iso server_freeipa_replication_replica
URL: https://openqa.fedoraproject.org/tests/439814
ID: 439815  Test: x86_64 Server-dvd-iso server_realmd_join_kickstart 
**GATING**
URL: https://openqa.fedoraproject.org/tests/439815
ID: 439817  Test: x86_64 Server-dvd-iso realmd_join_sssd **GATING**
URL: https://openqa.fedoraproject.org/tests/439817
ID: 439818  Test: x86_64 Server-dvd-iso server_freeipa_replication_client
URL: https://openqa.fedoraproject.org/tests/439818
ID: 439823  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/439823
ID: 439827  Test: x86_64 Server-dvd-iso realmd_join_cockpit
URL: https://openqa.fedoraproject.org/tests/439827
ID: 439828  Test: x86_64 Everything-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/439828
ID: 439829  Test: x86_64 Everything-boot-iso install_default@uefi **GATING**
URL: https://openqa.fedoraproject.org/tests/439829
ID: 439831  Test: x86_64 Workstation-live-iso install_default_upload 
**GATING**
URL: https://openqa.fedoraproject.org/tests/439831
ID: 439833  Test: x86_64 Workstation-live-iso install_default@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/439833
ID: 439861  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/439861
ID: 439882  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/439882
ID: 439889  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/439889
ID: 439915  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/439915
ID: 439917  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/439917
ID: 439918  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/439918
ID: 439920  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/439920
ID: 439924  Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/439924
ID: 439925  Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/439925
ID: 439926  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/439926
ID: 439929  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/439929

Passed openQA tests: 104/142 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20190901.n.0):

ID: 439855  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/439855

Skipped gating openQA tests: 4/142 (x86_64)

Old skipped gating tests (same test skipped in Fedora-Rawhide-20190901.n.0):

ID: 439837  Test: x86_64 Workstation-live-iso base_update_cli **GATING**
URL: https://openqa.fedoraproject.org/tests/439837
ID: 439838  Test: x86_64 Workstation-live-iso base_system_logging **GATING**
URL: https://openqa.fedoraproject.org/tests/439838
ID: 439840  Test: x86_64 Workstation-live-iso desktop_terminal **GATING**
URL: https://openqa.fedoraproject.org/tests/439840
ID: 439841  Test: x86_64 Workstation-live-iso desktop_browser **GATING**
URL: https://openqa.fedoraproject.org/tests/439841

Skipped non-gating openQA tests: 9 of 144

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
Used mem changed from 780 

[Bug 1747549] perl-PPIx-Regexp-0.067 is available

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
FEDORA-2019-497b4dea59 has been submitted as an update to Fedora 30.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-497b4dea59

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

[Bug 1747549] perl-PPIx-Regexp-0.067 is available

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
FEDORA-2019-0cb94dfc85 has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-0cb94dfc85

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

[Bug 1747549] perl-PPIx-Regexp-0.067 is available

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-PPIx-Regexp-0.067-1.fc
   ||32



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for Fedora ≥ 30.

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

Re: Orphaned packages looking for new maintainers

[Fabio Valentini]

On Mon, Sep 2, 2019 at 12:02 PM Miro Hrončok  wrote:

(snip)

> stewardship-sig: logback, gpars, groovy, gmavenplus-plugin

I submitted a new build for maven yesterday which removes its
dependency on logback, which in turn also means we no longer depend on
gpars, groovy, or gmavenplus-plugin.

Which means we're done with adopting orphaned packages we need for now ;)

Fabio

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

Orphaned packages looking for new maintainers

[Miro Hrončok]

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via releng issues:
https://pagure.io/releng/issues

Full report available at:
https://churchyard.fedorapeople.org/orphans-2019-09-02.txt
grep it for your FAS username and follow the dependency chain.

Package  (co)maintainers   Status Change

7kaa  orphan, raphgro  5 weeks ago
99soft-oss-parent orphan   5 weeks ago
HikariCP  lef, orphan  5 weeks ago
R-ALL orphan   1 weeks ago
R-AnnotationDbi   orphan   1 weeks ago
R-BSgenomeorphan   1 weeks ago
R-BSgenome.Celegans.UCSC.ce2  orphan   1 weeks ago
R-Biobase orphan   1 weeks ago
R-BiocGenericsorphan   1 weeks ago
R-Biostrings  orphan   1 weeks ago
R-BufferedMatrix  orphan   1 weeks ago
R-BufferedMatrixMethods   orphan   1 weeks ago
R-DynDoc  orphan   1 weeks ago
R-GenomicFeatures orphan   1 weeks ago
R-GenomicRanges   orphan   1 weeks ago
R-IRanges orphan   1 weeks ago
R-ROC orphan   1 weeks ago
R-affyorphan   1 weeks ago
R-affydataorphan   1 weeks ago
R-affyio  orphan   1 weeks ago
R-fibroEset   orphan   1 weeks ago
R-hgu133acdf  orphan   1 weeks ago
R-hgu95av2cdf orphan   1 weeks ago
R-hgu95av2probe   orphan   1 weeks ago
R-maanova orphan   1 weeks ago
R-multtestalexlan, orphan  1 weeks ago
R-pls orphan   1 weeks ago
R-preprocessCore  orphan   1 weeks ago
R-rlecuyerloveshack, orphan1 weeks ago
R-statmod orphan   1 weeks ago
R-tkWidgets   orphan   1 weeks ago
R-widgetTools orphan   1 weeks ago
Xnee  orphan   2 weeks ago
access-modifier-annotationmizdebsk, orphan 0 weeks ago
accumulo  ctubbsii, milleruntime,  2 weeks ago
  mizdebsk, orphan
acegisecurity mizdebsk, orphan 0 weeks ago
adevs orphan   2 weeks ago
airline   lef, orphan  5 weeks ago
akuma orphan   0 weeks ago
android-json-org-java mizdebsk, orphan 5 weeks ago
android-opengl-apiorphan   5 weeks ago
annogen   orphan   5 weeks ago
annotation-indexermizdebsk, orphan 0 weeks ago
annox orphan   5 weeks ago
apache-commons-chain  orphan   5 weeks ago
apache-commons-configuration2 java-sig, orphan 5 weeks ago
apache-commons-csvmizdebsk, orphan, spike  0 weeks ago
apache-commons-discovery  lkundrak, mizdebsk, orphan,  0 weeks ago
  spike
apache-commons-el fnasser, mizdebsk, orphan,   0 weeks ago
  spike

Re: GNOME 3.33.92 megaupdate

[Frantisek Zatloukal]

I don't think it's that late for FE for F31 Beta, but this is something we
can discuss on our meeting tomorrow.

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

Re: [Test-Announce] Fedora 31 Beta Freeze

[Nicolas Mailhot via devel]

Le 2019-08-31 10:44, Zbigniew Jędrzejewski-Szmek a écrit :


(I asked a few people what 24:00 means to them, and after getting a
few strange looks and answers,


To be fair:

1. ISO 8501 allows writing 24:00

Wikipedia> Midnight is a special case and may be referred to as either 
"00:00" or "24:00". The notation "00:00"
Wikipedia> is used at the beginning of a calendar day and is the more 
frequently used. At the end of a day use
Wikipedia> "24:00". "2007-04-05T24:00" is the same instant as 
"2007-04-06T00:00"


2. However the IETF explicitely forbid it when defining the ISO 8501 
subset allowed on the Internet


RFC 3339> Although ISO 8601 permits the hour to be "24", this profile of 
ISO
RFC 3339> 8601 only allows values between "00" and "23" for the hour in 
order

RFC 3339> to reduce confusion.

Therefore, banning the 24:00 notation is necessary for interoperability, 
even if one does not agree with the IETF decision. (00:00 however is 
well-defined and not ambiguous)


Regards,

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

GNOME 3.33.92 megaupdate

[Kalev Lember]

Hi all,

I've requested a side tag from releng to build 3.33.92 and 3.34.x updates
for F31. Once we have the side target, please use it for 3.33.92 builds and
I'll pick them up for the next megaupdate for Bodhi. I'll run point on
getting most of the builds done.

I suspect 3.33.92 is too late for a freeze exception for F31 beta, but I
think it's still best to keep things together for now.

'fedpkg build --target f31-gnome' should start working once we get the side
tag.

Side tag request: https://pagure.io/releng/issue/8722

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

[Bug 1543336] please provide missing Fedora 27 Perl modules

[bugzilla]

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



--- Comment #22 from Paul Howarth  ---
All current Fedora releases have a CryptX-based version of Net-SSH-Perl now,
though most of the ECC-related functionality is missing as it was stripped out
of perl-CryptX.

Would that be OK for you if it was in EPEL-7?

I don't know if Petr is prepared to build this hobbled perl-CryptX for EPEL.

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

[Bug 1747079] perl-File-Next-1.18 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-2019-b5f8ae29e2 has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-b5f8ae29e2

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

[Bug 1746257] Upgrade perl-File-Next to 1.18

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2019-b5f8ae29e2 has been submitted as an update to Fedora 31.
https://bodhi.fedoraproject.org/updates/FEDORA-2019-b5f8ae29e2

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

Re: f32/rawhide, nothing provides module(platform:f31)

[Igor Gnatenko]

Well,

Whatever you set in the defaults, DNF ignores that on the update.

https://pagure.io/releng/fedora-module-defaults/blob/master/f/libgit2.yaml
https://pagure.io/releng/fedora-module-defaults/blob/f31/f/libgit2.yaml

On Mon, Sep 2, 2019 at 9:08 AM Miroslav Suchý  wrote:
>
> Dne 30. 08. 19 v 18:25 Adam Williamson napsal(a):
> > Not. If you're getting it on an installed system that you're upgrading,
>
> Yes.
>
> > you probably need to manually switch the libgit2 module from the 0.27
> > stream to the 0.28 stream, that should clear it up.
>
> No. 0.27 is the platform default on F30. If the default should be different 
> on F31 then maintainer (cc igor), through
> rel-eng, should change it:
>   
> https://docs.fedoraproject.org/en-US/modularity/making-modules/managing-defaults/
>
> --
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: f32/rawhide, nothing provides module(platform:f31)

[Miroslav Suchý]

Dne 30. 08. 19 v 18:25 Adam Williamson napsal(a):
> Not. If you're getting it on an installed system that you're upgrading,

Yes.

> you probably need to manually switch the libgit2 module from the 0.27
> stream to the 0.28 stream, that should clear it up.

No. 0.27 is the platform default on F30. If the default should be different on 
F31 then maintainer (cc igor), through
rel-eng, should change it:
  
https://docs.fedoraproject.org/en-US/modularity/making-modules/managing-defaults/

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org