Re: RFC: Change the default hostname for Fedora 26+

[Nico Kadel-Garcia]

On Thu, Nov 10, 2016 at 9:21 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Thu, Nov 10, 2016 at 02:08:48PM +0100, Roberto Ragusa wrote:
>> On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
>> > On 11/09/2016 01:03 PM, Richard W.M. Jones wrote:
>>
>> >> Having it CAPS doesn't sound very nice ...
>> >>
>> >
>> > Yeah, that's fine. I was kind of copying off the windows approach, but I 
>> > really don't care at all whether we present it in lower-case or upper-case 
>> > as long as it's consistent.
>>
>> All lower case, please.
>> Lower case is the default everywhere in Unix, and the hostname also contains
>> an Internet related meaning, where only lower case is used.
>
> Nah, the internet is case-insensitive. And Fedora is a name, starts with
> a capital letter.

DNS is all translated to lower case, RFC 4343. AddInG CamelCase ThaT
WilL BE igNOReD bY coDE LeaDs To UnneCEssarY CompLeXitY AnD MisMatcHEd
AnD MisSpeEd ConfIGUraTIonZ.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1393421] perl-Error broke the most of perl apps.

[bugzilla]

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



--- Comment #14 from Fedora Update System  ---
perl-5.22.2-364.fc24 has been pushed to the Fedora 24 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-2016-7cf2994d15

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

[389-devel] Please review: Automatic thread tuning

[William Brown]

Hi,

This is the simpler of the two autotuning topics, focused mainly on
threads only, with a small static dbcache increase. See trac comments
for more. 

https://fedorahosted.org/389/ticket/49021

https://fedorahosted.org/389/attachment/ticket/49021/0001-Ticket-49021-Automatic-thread-tuning.patch

-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane


signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Thu, 2016-11-10 at 21:44 -0500, Josh Boyer wrote:
> On Thu, Nov 10, 2016 at 5:09 PM, Adam Williamson
>  wrote:
> > On Thu, 2016-11-10 at 13:31 -0800, Chris Murphy wrote:
> > > https://meetbot.fedoraproject.org/fedora-meeting-2/2016-11-10/f25-final-gono-go-meeting.2016-11-10-17.00.log.html
> > > 
> > > > > > 17:10:26  i can't really vote -1 on this under the current 
> > > > > > criteria unless someone tries on a newer mac and it works. but 
> > > > > > given 
> > > > > > https://www.happyassassin.net/testcase_stats/25/Installation/QA_Testcase_dualboot_with_OSX_Miscellaneous.html
> > > > > >  , i am entirely open to dropping the criterion on the basis of 
> > > > > > failure to test.
> > > 
> > > 
> > > I think it's specious to drop the criterion on this basis. There are
> > > plenty of other things that don't get tested and their criterion don't
> > > get dropped.
> > 
> > I am actually planning to propose precisely this.
> 
> My sincere apologies for not being in the meeting.  I could not attend
> due to a conflict with a different meeting.
> 
> I am somewhat befuddled at the decision to block the entire release
> for this issue.  We seem to have created a criteria under the premise
> that "lots of people have Macs and want to run Linux/Fedora on them",
> yet our empirical data seems to have shown a distinct lack of testing
> that would bear that premise out.

The premise under which the criterion was created was basically
that "the Workstation technical specification included it". Here's the
whole paper trail for the criterion:

Workstation tech spec - 
https://fedoraproject.org/wiki/Workstation/Technical_Specification :

"One aspect of storage configuration that will be needed is support for
dual-boot setups (preserving preexisting Windows or OS X
installations), since e.g. students may be required to run software on
those platforms for their coursework."

This led to:

desktop@ discussion - 
https://lists.fedoraproject.org/pipermail/desktop/2014-June/009932.html :

"1a. Does preserve preexisting include providing a working menu entry
in the boot manager (e.g. in the GRUB menu)? 
1b. Or is it sufficient to just preserve the installation data —
meaning it's permissible for its bootability to be either non-obvious
or broken?"

Excursions and alarums, etc. etc. followed, till eventually mcatanzaro
posted a...

test@ list proposal - 
https://lists.fedoraproject.org/pipermail/test/2014-August/122496.html :

"Since our Mac support is very poor and has no prospect of near term
improvement -- in particular, we have concerns that running Fedora on a
Mac has caused at least one Mac to overheat and die -- the consensus
seems to be that dual booting with OS X should not be a requirement."

There was an initial wording proposal, some more discussion, and then I
posted a...

final proposal - 
https://lists.fedoraproject.org/pipermail/test/2014-September/123012.html :

"The installer must be able to install into free space alongside an
existing OS X installation, install and configure a bootloader that will
boot Fedora; if the boot menu presents OS X entries, they should boot OS
X."

which is the wording that remains. Note that it specifically does not
require that OS X keeps working, but it *does* require that the Fedora
installation actually boots.

> I agree 100% that lots of people have Macs.  I agree in part that
> people want to run Linux/Fedora on them.  I agree that a subset of
> those that want to run Linux on a Mac also want to dual-boot OS X.
> What I cannot get my head around though is how we've essentially made
> a decision based on perceived marketing value of those target users at
> the expense of every other platform we support.  Our engineering and
> testing resources are clearly not sufficient to cover this case.  If
> they are, then we have a fairly large communication problem
> illustrated here.  Or if that wasn't the reason, and it was simply
> "because we have a criteria written down" that also seems somewhat
> myopic.

It's important to note that we may not have the full story on testing
here. At the meeting I said that no-one had tested this throughout the
cycle; this was based on the fact that no-one has filled out a result
for the test in the wiki pages throughout the cycle. However, since the
meeting, Chris Murphy has said in the bug that he *has* tested dual
boot install during the Fedora 25 cycle and found that it worked.

Given my analysis of the bug I find that a bit surprising, but I can
see (I think) one possible scenario in which the install might possibly
work (if there was an existing Fedora install on the system). So that
might be what happened there.

Anyway, point is, we *do* have some testing resources. However, I do
mean to try and do a sweep through the criteria and test cases after
the F25 release and try to highlight areas where test coverage is not
sufficient (where 'sufficient' means we have at least two people and/or
a bot regularly testing 

Re: Fedora on Macs, removing the release criterion

[Josh Boyer]

On Thu, Nov 10, 2016 at 5:09 PM, Adam Williamson
 wrote:
> On Thu, 2016-11-10 at 13:31 -0800, Chris Murphy wrote:
>> https://meetbot.fedoraproject.org/fedora-meeting-2/2016-11-10/f25-final-gono-go-meeting.2016-11-10-17.00.log.html
>>
>> > > > 17:10:26  i can't really vote -1 on this under the current 
>> > > > criteria unless someone tries on a newer mac and it works. but given 
>> > > > https://www.happyassassin.net/testcase_stats/25/Installation/QA_Testcase_dualboot_with_OSX_Miscellaneous.html
>> > > >  , i am entirely open to dropping the criterion on the basis of 
>> > > > failure to test.
>>
>>
>> I think it's specious to drop the criterion on this basis. There are
>> plenty of other things that don't get tested and their criterion don't
>> get dropped.
>
> I am actually planning to propose precisely this.

My sincere apologies for not being in the meeting.  I could not attend
due to a conflict with a different meeting.

I am somewhat befuddled at the decision to block the entire release
for this issue.  We seem to have created a criteria under the premise
that "lots of people have Macs and want to run Linux/Fedora on them",
yet our empirical data seems to have shown a distinct lack of testing
that would bear that premise out.

I agree 100% that lots of people have Macs.  I agree in part that
people want to run Linux/Fedora on them.  I agree that a subset of
those that want to run Linux on a Mac also want to dual-boot OS X.
What I cannot get my head around though is how we've essentially made
a decision based on perceived marketing value of those target users at
the expense of every other platform we support.  Our engineering and
testing resources are clearly not sufficient to cover this case.  If
they are, then we have a fairly large communication problem
illustrated here.  Or if that wasn't the reason, and it was simply
"because we have a criteria written down" that also seems somewhat
myopic.

Please don't misunderstand me.  I want this to work and I think it is
valuable.  I also appreciate everyone pitching in at the last minute
and I'm sure it will get fixed.  However, I think we really need to
take a strong look at what our Project can sustain, the value of the
distribution as a whole across all Editions and platforms, and the
resulting impacts of every possible slip.  The conversation I read in
the IRC logs does not seem to reflect that, and despite people wishing
for "not hero-ing" that seems like exactly what happened and will
continue to happen, extending even into the release itself over a
major holiday.

We are technical people and bugs bother us and we want to fix them.
Yet, we need to make judgement calls on blockers based on reality and
overall benefit/cost of blocking the release, not because we have a
known root-cause at the last minute and can probably fix it if we
slip.  That way lies madness and we'll continue to have further
arguments about playing catch-up in the schedule with a shorter cycle
next release, etc.  How can we ensure that we balance that with a
broader focus across the Project so that we don't continue to have
problems of our own making?

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

[389-devel] Jenkins build is back to normal : 389-DS-NIGHTLY #128

[Jenkins]

See 

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

[EPEL-devel] Looking for testers for Nagios 4.2.2

[Stephen John Smoogen]

Petaris and I put together an updated set of RPMs for nagios,
nagios-plugins and nrpe that need testing. I have built them in a copr
of

https://copr.fedorainfracloud.org/coprs/smooge/Nagios_Update/repo/epel-7/smooge-Nagios_Update-epel-7.repo

I know that currently these do not build for RHEL-6 or Rawhide. I need
to track down those but want to get an idea on what has been done so
far will work for users.

Thank you.


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

tibbs pushed to perl-Encode-IMAPUTF7 (master). "Initial spec and sources import."

[notifications]

From 27bceff70f472202375e19e7d79996a992532666 Mon Sep 17 00:00:00 2001
From: Jason Tibbitts 
Date: Thu, 10 Nov 2016 19:02:24 -0600
Subject: Initial spec and sources import.

---
 .gitignore|  3 +++
 perl-Encode-IMAPUTF7.spec | 52 +++
 sources   |  1 +
 3 files changed, 56 insertions(+)
 create mode 100644 perl-Encode-IMAPUTF7.spec

diff --git a/.gitignore b/.gitignore
index e69de29..6cf6477 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1,3 @@
+*.src.rpm
+/Encode-IMAPUTF7-1.05.tar.gz
+results-*/
diff --git a/perl-Encode-IMAPUTF7.spec b/perl-Encode-IMAPUTF7.spec
new file mode 100644
index 000..4a334ac
--- /dev/null
+++ b/perl-Encode-IMAPUTF7.spec
@@ -0,0 +1,52 @@
+%global remove_lf() for i in %*; do tr -d '\\r' < $i > $i. && touch $i $i. && 
mv -f $i. $i; done
+
+Name:   perl-Encode-IMAPUTF7
+Version:1.05
+Release:2%{?dist}
+Summary:Process the special UTF-7 variant required by IMAP
+License:GPL+ or Artistic
+URL:http://search.cpan.org/dist/Encode-IMAPUTF7/
+Source0:
http://www.cpan.org/authors/id/P/PM/PMAKHOLM/Encode-IMAPUTF7-%{version}.tar.gz
+BuildArch:  noarch
+
+BuildRequires:  make perl perl-generators
+BuildRequires:  perl(base) perl(Encode) perl(Encode::Encoding)
+BuildRequires:  perl(ExtUtils::MakeMaker) perl(File::Basename) perl(File::Spec)
+BuildRequires:  perl(MIME::Base64) perl(strict) perl(Test::More)
+BuildRequires:  perl(Test::NoWarnings) perl(warnings)
+
+Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+
+%description
+This module is able to encode and decode IMAP mailbox names using the UTF-7
+modification specified in RFC2060 section 5.1.3.
+
+%prep
+%autosetup -n Encode-IMAPUTF7-%{version}
+%remove_lf README Changes
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
+%make_build
+
+%install
+make pure_install DESTDIR=%buildroot
+%_fixperms %buildroot/*
+
+%check
+make test
+
+%files
+%doc Changes README
+%{perl_vendorlib}/*
+%_mandir/man3/*
+
+%changelog
+* Wed Nov 09 2016 Jason L Tibbitts III  - 1.05-2
+- Add more build dependencies.
+- Use DESTDIR instead of cpanspec-provided PERL_INSTALL_ROOT.
+- Build with NO_PACKLIST=1 and don't bother deleting .packlist files.
+
+* Wed Nov 02 2016 Jason Tibbitts  1.05-1
+- Specfile autogenerated by cpanspec 1.78.
+- Cleaned up the generated spec to meet current guidelines.
diff --git a/sources b/sources
index e69de29..acd2c53 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+2ef9d1a438f3fa29771d24f9e587fd2a  Encode-IMAPUTF7-1.05.tar.gz
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Encode-IMAPUTF7.git/commit/?h=master=27bceff70f472202375e19e7d79996a992532666
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs uploaded Encode-IMAPUTF7-1.05.tar.gz for perl-Encode-IMAPUTF7

[notifications]

2ef9d1a438f3fa29771d24f9e587fd2a  Encode-IMAPUTF7-1.05.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Encode-IMAPUTF7/Encode-IMAPUTF7-1.05.tar.gz/md5/2ef9d1a438f3fa29771d24f9e587fd2a/Encode-IMAPUTF7-1.05.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Django stable RPMs

[Orion Poplawski]

On 11/09/2016 03:13 AM, Stephen Finucane wrote:
> On 2016-11-08 18:06, Matthias Runge wrote:
>> On 08/11/16 16:31, Brian Bouterse wrote:
>>> I believe the future of Django in EPEL is a topic that is being
>>> discussed on the EPSCO meetings last week and this week (18:00 UTC on
>>> Wednesdays in #fedora-meeting, iirc).
>>>
>>> I'm hoping that even if a newer, 1.8 based Django package is added to
>>> EPEL6, that the existing one named Django14 can be kept for legacy
>>> usage. The Django14 package having that unconventional name would allow
>>> a new package to use the more conventional python-django name which is
>>> convenient.
>>
>> I believe I can shed a light here:
>> - Django14 followed the old Django naming scheme in Fedora. Django was
>> renamed to python-django there.
>> - Django-1.4 was the old long term supported version and works with
>> pythons up to python 2.6
>> - Django14 should be retired IMO
> 
> I agree. It's rather decrepit at this point.
> 
>> - Django-1.8 (current long term supported version) requires python 2.7.
>> That means, we can not have a recent Django in EPEL6 with system python.
> 
> Per the docs [1]
> 
>   Django 1.8 requires Python 2.7, 3.2, 3.3, 3.4, or 3.5
> 
> EPEL 7 comes with Python 3.4, correct? If so, 'python3-django' seems like a
> thing that can be done.

We are building up a Python 3.4 stack on EPEL 6 & 7, so that is an option.

I'm also poking at Python 2.7 on EPEL6 here:
https://copr.fedorainfracloud.org/coprs/g/python/python2.7_epel6/packages/

Anyone in the python sig group and build there and play along/help out.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Adam Williamson]

On Thu, 2016-11-10 at 13:31 -0800, Chris Murphy wrote:
> https://meetbot.fedoraproject.org/fedora-meeting-2/2016-11-10/f25-final-gono-go-meeting.2016-11-10-17.00.log.html
> 
> > > > 17:10:26  i can't really vote -1 on this under the current 
> > > > criteria unless someone tries on a newer mac and it works. but given 
> > > > https://www.happyassassin.net/testcase_stats/25/Installation/QA_Testcase_dualboot_with_OSX_Miscellaneous.html
> > > >  , i am entirely open to dropping the criterion on the basis of failure 
> > > > to test.
> 
> 
> I think it's specious to drop the criterion on this basis. There are
> plenty of other things that don't get tested and their criterion don't
> get dropped.

I am actually planning to propose precisely this.

>  It's always a last minute rush to test things like active
> directory,

We have this testing fairly well covered now.

>  Free IPA,

This is now tested automatically by openQA (so we already have had
several F26 blockers for it filed and fixed...)

>  iSCSI,

Ditto this.

>  you know the list way better than I do, so
> I don't know why you're picking on this one in contrast to others.

We've talked about it before, but I think we could stand to tighten
down on it better. There may be some things it kinda makes sense to
have in the criteria without an explicit testing plan that 100% covers
them, but at the very least we need to reconsider it.

Still, you've said in the bug that you actually were testing OS X dual
boot, just not filing results, which changes the picture there a bit.
We need to get more data before we can draw any conclusions, though.

> So feel free to drop the pretty UI/Ux going forward if maintaining
> that is going to cause problems, 

This might be a good idea (thanks for reminding me about the weird
wrinkle with how this works, pjones did also).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

tibbs changed tibbs's package request for perl-Encode-IMAPUTF7 in f25 from Awaiting Review to Approved

[notifications]

tibbs changed tibbs's package request for perl-Encode-IMAPUTF7 in f25 from 
Awaiting Review to Approved
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs changed tibbs's 'watchcommits' permission on perl-Encode-IMAPUTF7 (f24) to 'Approved'

[notifications]

tibbs changed tibbs's 'watchcommits' permission on perl-Encode-IMAPUTF7 (f24) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs changed tibbs's 'watchcommits' permission on perl-Encode-IMAPUTF7 (f25) to 'Approved'

[notifications]

tibbs changed tibbs's 'watchcommits' permission on perl-Encode-IMAPUTF7 (f25) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs changed tibbs's package request for perl-Encode-IMAPUTF7 in master from Awaiting Review to Approved

[notifications]

tibbs changed tibbs's package request for perl-Encode-IMAPUTF7 in master from 
Awaiting Review to Approved
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs changed tibbs's 'approveacls' permission on perl-Encode-IMAPUTF7 (f25) to 'Approved'

[notifications]

tibbs changed tibbs's 'approveacls' permission on perl-Encode-IMAPUTF7 (f25) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs created the branch 'f24' for the package 'perl-Encode-IMAPUTF7'

[notifications]

tibbs created the branch 'f24' for the package 'perl-Encode-IMAPUTF7'
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs changed tibbs's 'watchbugzilla' permission on perl-Encode-IMAPUTF7 (f24) to 'Approved'

[notifications]

tibbs changed tibbs's 'watchbugzilla' permission on perl-Encode-IMAPUTF7 (f24) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs changed tibbs's 'approveacls' permission on perl-Encode-IMAPUTF7 (f24) to 'Approved'

[notifications]

tibbs changed tibbs's 'approveacls' permission on perl-Encode-IMAPUTF7 (f24) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs changed tibbs's 'watchbugzilla' permission on perl-Encode-IMAPUTF7 (f25) to 'Approved'

[notifications]

tibbs changed tibbs's 'watchbugzilla' permission on perl-Encode-IMAPUTF7 (f25) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs changed tibbs's 'commit' permission on perl-Encode-IMAPUTF7 (f24) to 'Approved'

[notifications]

tibbs changed tibbs's 'commit' permission on perl-Encode-IMAPUTF7 (f24) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs changed tibbs's package request for perl-Encode-IMAPUTF7 in f24 from Awaiting Review to Approved

[notifications]

tibbs changed tibbs's package request for perl-Encode-IMAPUTF7 in f24 from 
Awaiting Review to Approved
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs changed tibbs's 'watchcommits' permission on perl-Encode-IMAPUTF7 (master) to 'Approved'

[notifications]

tibbs changed tibbs's 'watchcommits' permission on perl-Encode-IMAPUTF7 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs changed tibbs's 'watchbugzilla' permission on perl-Encode-IMAPUTF7 (master) to 'Approved'

[notifications]

tibbs changed tibbs's 'watchbugzilla' permission on perl-Encode-IMAPUTF7 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs changed tibbs's 'commit' permission on perl-Encode-IMAPUTF7 (f25) to 'Approved'

[notifications]

tibbs changed tibbs's 'commit' permission on perl-Encode-IMAPUTF7 (f25) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs changed perl-sig's 'watchcommits' permission on perl-Encode-IMAPUTF7 (master) to 'Approved'

[notifications]

tibbs changed perl-sig's 'watchcommits' permission on perl-Encode-IMAPUTF7 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs changed perl-sig's 'watchbugzilla' permission on perl-Encode-IMAPUTF7 (master) to 'Approved'

[notifications]

tibbs changed perl-sig's 'watchbugzilla' permission on perl-Encode-IMAPUTF7 
(master) to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs created the branch 'f25' for the package 'perl-Encode-IMAPUTF7'

[notifications]

tibbs created the branch 'f25' for the package 'perl-Encode-IMAPUTF7'
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs changed tibbs's 'commit' permission on perl-Encode-IMAPUTF7 (master) to 'Approved'

[notifications]

tibbs changed tibbs's 'commit' permission on perl-Encode-IMAPUTF7 (master) to 
'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs changed perl-sig's 'commit' permission on perl-Encode-IMAPUTF7 (master) to 'Approved'

[notifications]

tibbs changed perl-sig's 'commit' permission on perl-Encode-IMAPUTF7 (master) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

tibbs changed tibbs's 'approveacls' permission on perl-Encode-IMAPUTF7 (master) to 'Approved'

[notifications]

tibbs changed tibbs's 'approveacls' permission on perl-Encode-IMAPUTF7 (master) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Encode-IMAPUTF7/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Fedora on Macs, removing the release criterion

[Chris Murphy]

https://meetbot.fedoraproject.org/fedora-meeting-2/2016-11-10/f25-final-gono-go-meeting.2016-11-10-17.00.log.html

>>>17:10:26  i can't really vote -1 on this under the current criteria 
>>>unless someone tries on a newer mac and it works. but given 
>>>https://www.happyassassin.net/testcase_stats/25/Installation/QA_Testcase_dualboot_with_OSX_Miscellaneous.html
>>> , i am entirely open to dropping the criterion on the basis of failure to 
>>>test.


I think it's specious to drop the criterion on this basis. There are
plenty of other things that don't get tested and their criterion don't
get dropped. It's always a last minute rush to test things like active
directory, Free IPA, iSCSI, you know the list way better than I do, so
I don't know why you're picking on this one in contrast to others.

>>>17:12:02  I've never understood why we would block on failures to 
>>>run on hardware that actively tries to make it difficult to run Linux on.

Please elaborate on what this means. Specifically I have no idea what
the word "actively" is referring to.



>>>17:20:03  oh that's right, Apple decided to have HFS+ formatted 
>>>'ESP'. because they're assholes.

No, Macs have a FAT32 ESP just like other hardware does. And it can
use a bootloader on that ESP just like other hardware does. It's how
Ubuntu and openSUSE work on Macs.

It's Anaconda and mactel-boot that make an hfsplus ESP, in order to
trick the firmware into thinking the Fedora bootloaders are a macOS
instance, so that the Mac's bootloader and startup panel will show
Fedora as a boot option. openSUSE and Ubuntu aren't as pretty but
things still work in a more standardized fashion.

So feel free to drop the pretty UI/Ux going forward if maintaining
that is going to cause problems, but I don't see how Fedora meets its
goals by claiming Macs make things difficult for Linux, when in this
Go No Go meeting is a pre-plan to actively make Fedora more difficult
to use on Macs.



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

Re: RFC: Change the default hostname for Fedora 26+

[stan]

On Thu, 10 Nov 2016 12:40:23 -0500
Stephen John Smoogen  wrote:

> On 10 November 2016 at 12:11, Adam Williamson
>  wrote:
> > On Thu, 2016-11-10 at 09:58 -0700, stan wrote:  

> >> Or am I missing something?  
> >
> > How exactly are you planning to check for collisions with hosts that
> > are shut down or somewhere else (laptops)?  
> 
> Or even how are you going to communicate that there is another machine
> of that name? That is a registration and command and control issue in
> a completely different 'stack' than the installer usually is in.

So I was missing something.  :-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Should we stop stripping static libraries?

[Orion Poplawski]

On 11/10/2016 12:16 PM, Florian Weimer wrote:
> We currently call /usr/lib/rpm/brp-strip-static-archive from
> %__os_install_post.  This removes debugging symbols from static (.a) 
> libraries.
> 
> Is this really a good idea?  Due to this, glibc copies libc.a to
> glibc-debuginfo, so that you can get a link with debugging symbols by
> specifying “-static -L/usr/lib/debug/usr/lib64“ (potentially with unintended
> side effects).  I would like to get this to work by default.
> 
> If developers does not want debugging symbols and static libraries have them,
> they can link with -s, or strip the linked object.
> 
> Thoughts?

Having run into difficulty with debugging programs linked to static libraries
before, I would like to see this fixed.  It seems like a reasonable plan, but
I don't have any technical knowledge here.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 Final Release Readiness Meeting, Thursday, November 10th @ 19:00 UTC

[Jan Kurik]

On Mon, Nov 7, 2016 at 2:35 PM, Jan Kurik  wrote:
> Join us on irc.freenode.net in #fedora-meeting-2 for the Fedora 25
> Final Release Readiness Meeting meeting.
>
> The meeting is going to be held on Thursday, November 10th, 2016 at
> 19:00 UTC. Please check the [FedoCal] link for your time zone.
>
> We will meet to make sure we are coordinated and ready for the Final
> release of Fedora 25. Please note that this meeting is going to be
> held even if the release is delayed at the Go/No-Go meeting on the
> same day two hours earlier.
>
> You may received this message several times, but it is by purpose to
> open this meeting to the teams and to raise awareness, so hopefully
> more team representatives will come to this meeting. This meeting
> works best when we have representatives from all of the teams.
>
> [FedoCal] https://apps.fedoraproject.org/calendar/meeting/4855/
>
> More information available at:
> https://fedoraproject.org/wiki/Release_Readiness_Meetings
>
> Thank you for your support and Regards, Jan

Thank you all folks for joining the meeting, or sending me the status off-line.

The current status of the release is NO-GO due to a present blocker.
However, as shown during the meeting, we are ready for the release
once we have a new compose with GO status. For more information,
please check the minutes [1][2].

[1] 
https://meetbot.fedoraproject.org/fedora-meeting-2/2016-11-10/f25-final-readiness-meeting.2016-11-10-19.23.html
[2] 
https://meetbot.fedoraproject.org/fedora-meeting-2/2016-11-10/f25-final-readiness-meeting.2016-11-10-19.23.log.html

Regards,
Jan

-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Change the default hostname for Fedora 26+

[Zbigniew Jędrzejewski-Szmek]

On Thu, Nov 10, 2016 at 08:02:20PM +0100, Lennart Poettering wrote:
> Other operating systems, notably security-focussed ones like ChromeOS,
> go the other way, and try to remove as many identifiers as possible
> that could be used to track users. In fact, at LPC we discussed even
> making /etc/machine-id an optional concept in that context, so that
> there really would not be any useful local ID that could leak to
> external systems.

Saying that ChromeOS "tries to removes as many identifiers as possible
that could be used to track users" is a joke: the whole purpose of that
OS is to track users ;) The only difference is in who does the tracking.

> I must say I sympathise with ChromeOS approach there, I think it would
> make sense to default to more secure default in this regard, rather
> than opening this all up.

It certainly is good to protect privacy in some environments, but at
the same time, there are various use-cases where being able to easily
identify the machine is crucial for usability: soho networks,
wifi sharing, any kind of setup where you want to share data in an
ad-hoc setting, printing, freeipa, etc. In fact systemd itself follows
this kind of logic: LLDP, LLMNR is enabled on "trusted" networks.

If I'm in a trusted network, where I can identify the machines anyway,
making me jump through hoops like manually checking MAC addresses or
comparing IP numbers to guess which machine is which is pointless.

And disabling the hostname does not really buy much: anyone with
control over the network are likely to be able to identify the machine
using MAC address, the DNS queries it performs, and other access
patterns.  If we resolve https://fedoraproject.org/static/hotspot.txt
immediately after connecting, the information that the hostname is
"Fedora-X" does not change anything.

I think we should work on not leaking the hostname in untrusted
settings (which effectively means "unless told otherwise"), and not
trying to make the machine completely anonymous.

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

Fedora 25 Final status is NO-GO

[Jan Kurik]

The result for the Go/No-Go meeting for the Fedora 25 Final release is NO-GO.

Due to a present blocker [1] the decision is to slip the Fedora 25
Final release for a week. The new GA data is planned on 2016-Nov-22.
More information can be found in the meeting minutes [2][3].

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1393846
[2] 
https://meetbot.fedoraproject.org/fedora-meeting-2/2016-11-10/f25-final-gono-go-meeting.2016-11-10-17.00.html
[3] 
https://meetbot.fedoraproject.org/fedora-meeting-2/2016-11-10/f25-final-gono-go-meeting.2016-11-10-17.00.log.html

Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Change the default hostname for Fedora 26+

[Stephen John Smoogen]

On 10 November 2016 at 15:06, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Thu, Nov 10, 2016 at 10:18:21AM -0500, Stephen John Smoogen wrote:
>> On 10 November 2016 at 09:27, Stephen Gallagher  wrote:
>> >
>> >>> On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
>>
>>
>> Here are the items I would like to point out:
>>
>> 1. The TLD name should be something that DNS considers a known unknown
>> name. With the fact that IANA is allowing top level domains of all
>> sorts we do not want to end up having .fedora  or .foobaz end up
>> causing thousands of computers saying they are in someones domain. So
>> .invalid .localhost .example .local or .test . I expect that
>> .localdomain might not ever be registered but who knows.
>
> Or better, don't provide any TLD. Plain local hostname is enough for
> all the purposes mentioned.
>
>> 2. The XX is rather important because of two conflicting items.
>> One we don't want it to be too short that collisions might occur a
>> lot, but we don't want it to be too long for readability but also the
>> less collisions the more likely it can be used to track people. If we
>> don't care about making breadcrumbs which could be used to 'track'
>> people we need to be clear about it so that people who are not wanting
>> that can steer clear. [My 'I am an idiot about randomness' solution
>> would be uuidgen | sum and that number is used for this. There is a
>> good chance of uniqueness per small site and non-uniqueness overall. ]
>
> I don't think you can have both. If the randomized part is long enough
> to have rare collisions, it'll certainly be good enough for tracking.
> If you consider that tracking can combine any external information
> (like the MAC address or anything else that it learns about the machine),
> tracking will "win" with many less bits of information.
>
> Instead, we should concentrate on not leaking the hostname in places
> where it shouldn't be leaked, for example on untrusted networks.

As in a later email, if that is what we are wanting, we need to design
that in earlier versus later because there will always be too many
ways to make something leaked for 'good intentions'. Rememeber, if
there is a screwdriver in the toolbox, some programmer is going to use
it as a hammer at some point because it was the first tool they pulled
out of the box. If there is a  /etc/machine-id it will get used
because it is the simplest tool to get a unique identifier for some
'important' thing.

In the end though there are severe limits to how 'anonymous' anyone
can make stuff with off the shelf hardware. Especially when the
majority of people aren't using your anonymous Operating System. The
fact that only 1% of the people aren't makes them clearer in large
datasets than if we just decided to make everything look like Windows
8.1 or Vista.

>> 3. case-sensitivity argument about Fedora or fedora looks to be a
>> bikeshed. There are probably local business reasons where having
>> caps/lowercase in names is important but in those cases they should
>> put in tools to conform to their local business reason.
> Ack.
>
> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



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

Re: RFC: Change the default hostname for Fedora 26+

[Zbigniew Jędrzejewski-Szmek]

On Thu, Nov 10, 2016 at 10:18:21AM -0500, Stephen John Smoogen wrote:
> On 10 November 2016 at 09:27, Stephen Gallagher  wrote:
> >
> >>> On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
> 
> 
> Here are the items I would like to point out:
> 
> 1. The TLD name should be something that DNS considers a known unknown
> name. With the fact that IANA is allowing top level domains of all
> sorts we do not want to end up having .fedora  or .foobaz end up
> causing thousands of computers saying they are in someones domain. So
> .invalid .localhost .example .local or .test . I expect that
> .localdomain might not ever be registered but who knows.

Or better, don't provide any TLD. Plain local hostname is enough for
all the purposes mentioned.

> 2. The XX is rather important because of two conflicting items.
> One we don't want it to be too short that collisions might occur a
> lot, but we don't want it to be too long for readability but also the
> less collisions the more likely it can be used to track people. If we
> don't care about making breadcrumbs which could be used to 'track'
> people we need to be clear about it so that people who are not wanting
> that can steer clear. [My 'I am an idiot about randomness' solution
> would be uuidgen | sum and that number is used for this. There is a
> good chance of uniqueness per small site and non-uniqueness overall. ]

I don't think you can have both. If the randomized part is long enough
to have rare collisions, it'll certainly be good enough for tracking.
If you consider that tracking can combine any external information
(like the MAC address or anything else that it learns about the machine),
tracking will "win" with many less bits of information.

Instead, we should concentrate on not leaking the hostname in places
where it shouldn't be leaked, for example on untrusted networks.

> 3. case-sensitivity argument about Fedora or fedora looks to be a
> bikeshed. There are probably local business reasons where having
> caps/lowercase in names is important but in those cases they should
> put in tools to conform to their local business reason.
Ack.

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

Re: RFC: Change the default hostname for Fedora 26+

[Stephen John Smoogen]

On 10 November 2016 at 14:04, Lennart Poettering  wrote:
> On Tue, 08.11.16 23:14, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
>> On Tue, Nov 08, 2016 at 05:25:36PM -0500, Matthew Miller wrote:
>> > On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
>> > > SUSE generates a random name of the format linux-XX (I'm not sure 
>> > > how many
>> > > My proposal is that we should consider changing the default hostname for 
>> > > Fedora
>> > > 26 to be either FED-XXX or FEDORA-. The former allows 
>> > > for a
>> >
>> > How about non-yelly Fedora-XXX? Since SUSE apparently does
>> > lower case, that should be fine, right?
>>
>> Bastian Nocera also filed 
>> https://bugzilla.redhat.com/show_bug.cgi?id=1392925,
>> where he proposes "fedora" as the hostname. I think "fedora" is better than
>> "localhost", and a non-constant hostname would be even better.
>> For interactive installs (like with anaconda) it would be great if we could
>> ask for the hostname. For non-interactive ones, "Fedora-[0-9a-z-]{8}" seems
>> like a good option (*). It would give "branding", and solve the freeipa 
>> issues.
>> It would also be a good default for the interactive case, so that people can
>> "click through" without having to pick anything.
>
> I'd be careful with this. I'd prefer a more generic default hostname
> over a more specific, so that we leak as little information about our
> system onto the network as possible.
>
> I mean, using "localhost.localdomain" is already leaky enough, given
> that only fedora is using this as default hostname — however, it's
> still better than telling everyone "Hay, I am running Fedora!".

The one thing to be aware of is that some of these items while useful
to fingerprint aren't as reliable as things we leak elsewhere like
kernel version/glibc version/compile time flags and how we respond to
TCP requests. Those usually leak a lot more and are much easier to get
even sneakily than localhost.localdomain or fedora-xx. You also
have to be careful about appearing too random [say changing the mac
address each connection.. it needs to change within certain noise
levels or you look "like someone with something to hide." versus
someone trying to blend in.]

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



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

[Bug 1393421] perl-Error broke the most of perl apps.

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #13 from Fedora Update System  ---
perl-5.24.0-379.fc25 has been pushed to the Fedora 25 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-2016-ab7085b1f4

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

[Bug 1238168] FTBFS: Failed during 'make check': 13netlink-message-attrs.t and 20io-socket-netlink-generic.t

[bugzilla]

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



--- Comment #11 from Fedora Update System  ---
perl-Socket-Netlink-0.04-17.fc25 has been pushed to the Fedora 25 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-2016-516414cec8

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

[Bug 1393198] perl-XML-XPath-1.39 is available

[bugzilla]

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



--- Comment #4 from Fedora Update System  ---
perl-XML-XPath-1.39-1.fc25 has been pushed to the Fedora 25 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-2016-daab3a66b6

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

Should we stop stripping static libraries?

[Florian Weimer]

We currently call /usr/lib/rpm/brp-strip-static-archive from 
%__os_install_post.  This removes debugging symbols from static (.a) 
libraries.


Is this really a good idea?  Due to this, glibc copies libc.a to 
glibc-debuginfo, so that you can get a link with debugging symbols by 
specifying “-static -L/usr/lib/debug/usr/lib64“ (potentially with 
unintended side effects).  I would like to get this to work by default.


If developers does not want debugging symbols and static libraries have 
them, they can link with -s, or strip the linked object.


Thoughts?

I can file a Fedora 26 system-wide change for this if this warrants one.

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

Re: RFC: Change the default hostname for Fedora 26+

[Lennart Poettering]

On Tue, 08.11.16 23:14, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> On Tue, Nov 08, 2016 at 05:25:36PM -0500, Matthew Miller wrote:
> > On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
> > > SUSE generates a random name of the format linux-XX (I'm not sure how 
> > > many
> > > My proposal is that we should consider changing the default hostname for 
> > > Fedora
> > > 26 to be either FED-XXX or FEDORA-. The former allows for 
> > > a
> > 
> > How about non-yelly Fedora-XXX? Since SUSE apparently does
> > lower case, that should be fine, right?
> 
> Bastian Nocera also filed https://bugzilla.redhat.com/show_bug.cgi?id=1392925,
> where he proposes "fedora" as the hostname. I think "fedora" is better than
> "localhost", and a non-constant hostname would be even better.
> For interactive installs (like with anaconda) it would be great if we could
> ask for the hostname. For non-interactive ones, "Fedora-[0-9a-z-]{8}" seems
> like a good option (*). It would give "branding", and solve the freeipa 
> issues.
> It would also be a good default for the interactive case, so that people can
> "click through" without having to pick anything.

I'd be careful with this. I'd prefer a more generic default hostname
over a more specific, so that we leak as little information about our
system onto the network as possible.

I mean, using "localhost.localdomain" is already leaky enough, given
that only fedora is using this as default hostname — however, it's
still better than telling everyone "Hay, I am running Fedora!".

Lennart

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

Re: RFC: Change the default hostname for Fedora 26+

[Lennart Poettering]

On Tue, 08.11.16 16:49, Stephen Gallagher (sgall...@redhat.com) wrote:

> For as long as I can recall, Fedora has shipped with a default hostname of
> "localhost.localdomain"[1]. This default was "safe" for a very long time 
> because
> we also shipped an /etc/hosts entry that routed this hostname to the loopback
> device for the benefit of some older system services (like sendmail).
> 
> However, having the default be the same on all systems introduces other
> problems, notably with regards to acting as a client to FreeIPA or Active
> Directory domain controllers.
> 
> When enrolling with one of these DCs, the machine's current hostname (up to 
> the
> first dot) is used to uniquely identify the machine into the domain. If the
> machine's hostname is not unique in that domain, the enrollment will either 
> fail
> or the machine will take over that name (depending on the server-side
> implementation). Neither case is likely to be what the user intended.
> 
> 
> Some information on competing platforms:
> 
> Windows deals with this on for its systems by assigning all new machines a
> random hostname of the form WIN-XXX (that's a strict count of 11 
> random
> characters of either capital letters or decimal numerals after the WIN- 
> prefix).
> This is because there is a 15-character maximum limit on the machine-name in
> Active Directory, after which it is simply truncated (which is a bad behavior,
> but one we have to deal with).
> 
> Mac OS X and Ubuntu both require the user to pick a machine name at install 
> time
> explicitly. They do not autogenerate one at all.
> 
> SUSE generates a random name of the format linux-XX (I'm not sure how many
> random characters).
> 
> 
> My proposal is that we should consider changing the default hostname for 
> Fedora
> 26 to be either FED-XXX or FEDORA-. The former allows for a
> longer random string and therefore lower risk of collision in large
> environments, while the latter would also provide improved branding for
> Fedora[2]. Our default BASH shell prompt includes the current machine's 
> hostname.
> 
> 
> Thoughts on how to generate these random strings are of course up for
> discussion. Given that initial machine creation may have limited available
> entropy, we may want to avoid just calling out to /dev/random. Dusty Mabe
> suggested in on IRC that one option might be to use either the first or last
> 8/11 characters from /etc/machine-id, since presumably those would be
> sufficiently random.

Other operating systems, notably security-focussed ones like ChromeOS,
go the other way, and try to remove as many identifiers as possible
that could be used to track users. In fact, at LPC we discussed even
making /etc/machine-id an optional concept in that context, so that
there really would not be any useful local ID that could leak to
external systems.

I must say I sympathise with ChromeOS approach there, I think it would
make sense to default to more secure default in this regard, rather
than opening this all up.

Now, I can see that it is useful for systems that install the IPA
client to behave differently here, and use some better hostname for
them, but I think this should only happen on those systems: I think a
good solution would be continue to use "localhost" as the Fedora
default hostname, but make the IPA enrollment code smart enough, so
that it recognizes that "localhost" is not useful as a public hostname
(it really should know this anyway!), and if it sees that
automatically changes the hostname to something more useful for IPA
clients. (changing the hostname in this case is easy, there's a
friendly bus API for that in hostnamed)

Hence, please keep this specific to IPA clients, don't let this leak
into the Fedora defaults.

(Also, please do not leak /etc/machine-id as it is — or any parts of
it — into identifiers that are passed onto the untrusted networks, in
particular as suffixes of hostnames. Instead, hash it with some
cryptographic, keyed hash function, and use a fixed, application-specific
key. That way the ID will be properly unique, and is derived in a
constant way from the machine ID but there's no way to derive the
original machine ID from the app-specific one. I figure this
recommendation should be added to the man page.)

Lennart

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

rubygem-launchy license change to ISC

[Vít Ondruch]

rubygem-launchy-2.4.3-1.fc26 changed it's license from BSD to ISC.


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

Re: Urgent call for testing: OS X dual boot

[Mauricio Tavares]

How old can the OSX box be? I have in a box an old Mac mini (Dual core
and can only officially supported to 10.7) I have no issues to put to
service.

On Thu, Nov 10, 2016 at 11:05 AM, Adam Williamson
 wrote:
> Hi, folks! We've had an F25 blocker proposed for failure to install as
> a dual boot with OS X:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1393846
>
> is there anyone who has an OS X system they can run this kind of test
> on (i.e. one they don't mind getting messed up if something goes
> wrong)? We would like more testing data so we can figure out if this is
> a system-specific issue or if all OS X dual boot is broken.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Change the default hostname for Fedora 26+

[Japheth Cleaver]

On 11/10/2016 8:45 AM, Richard W.M. Jones wrote:

On Thu, Nov 10, 2016 at 11:17:20AM +0100, Theodore Papadopoulo wrote:

On 11/09/2016 02:32 PM, Matthew Miller wrote:

On Tue, Nov 08, 2016 at 03:25:58PM -0800, Andrew Lutomirski wrote:

If the hostname is non-constant, can we also arrange that, by default,
this hostname is never sent over the network?  In particular, I think
that DHCP requests should *not* include this hostname.  We're already
starting to randomize MAC addresses -- there's no reason to give a
persistent per-installation identifier to every network.

There's two different cases that I'm not sure how to resolve elegantly.
On a home network or on a business network, having the name available
is highly desirable. On a public network, just the opposite.


Add a checkbox in nm so that users can state whether they are on a
trusted network or not ??

This is what Windows does.

I'm not sure it's a good idea for other reasons - almost no common
network should be "trusted" ...  Should you be sharing your machine
name on your home network that contains some insecure IoT crapware?

Rich.


It seems like that should be a policy decision made by an administrator 
or user (or at least the spin/distro builder), especially if the 
alternative means not having that flexibility at a low level of 
infrastructure.


We're still being gently nudged to be using NM on actual servers, right?

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

Re: RPM dependency generator ignoring %{_libdir}/pkg/plugin.so

[Richard W.M. Jones]

On Thu, Nov 10, 2016 at 04:48:59PM +, Richard W.M. Jones wrote:
> On Thu, Nov 10, 2016 at 04:44:53PM +, Tom Hughes wrote:
> > On 10/11/16 16:41, Richard W.M. Jones wrote:
> > 
> > >I'm packaging up a program that puts plugins into
> > >
> > >  %{_libdir}/pkg/plugin.so
> > >
> > >Unfortunately rpmbuild doesn't seem to generate automatic dependencies
> > >for these files (they are regular ELF files and I have checked that
> > >they contain DT_NEEDED fields).
> > >
> > >Any ideas on that?  There's a lot of documentation about how to
> > >exclude files from automatic dep generation, but I want to include
> > >these.
> > 
> > My guess would be that they're not marked as executable. Shared
> > libraries don't really need to be executable but they always have
> > been in Fedora and the dependency generator ignores ones which
> > aren't.
> 
> Very good catch!  Indeed they were not executable.  I'll see if
> setting proper mode fixes things.

Yes that's fixed it, thanks again.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Change the default hostname for Fedora 26+

[Stephen John Smoogen]

On 10 November 2016 at 12:11, Adam Williamson
 wrote:
> On Thu, 2016-11-10 at 09:58 -0700, stan wrote:
>> On Thu, 10 Nov 2016 11:21:13 -0500
>> Stephen John Smoogen  wrote:
>>
>> > So in any case, what I am suggesting is that we make a semi-unique
>> > identifier. It is unique enough that you won't get a collision in some
>> > 'target' space, but not so unique that it stands out like a black dot
>> > on a white shirt. Make the code adjustable somewhere in the process so
>> > that if someone wants it off, it can be done and if they need it to be
>> > a bigger space it can be done so.
>>
>> Isn't this pretty trivial to create?  We put a limit on the number of
>> machines that are accessible on a local network, say 10 million.  Then
>> we start at
>> Fedora-1.localhost.
>> e.g.
>> 'Fedora-' + str (counter) + '.localhost'
>>
>> So if there is only one computer on the local network it is named
>> Fedora-1.localhost.
>>
>> If there is more than one computer on the local network, we check for
>> collisions with names until we hit the next in numerical order that
>> isn't taken.
>>
>> while name_taken,
>>  counter += 1
>>  hostname = 'Fedora-' + str (counter) + '.localhost'
>>  name_taken = check_for_collision (hostname)
>>
>> This ensures there will be *lots* of collisions on the web, but zero
>> locally, at least for the first few hosts.
>>
>> Or am I missing something?
>
> How exactly are you planning to check for collisions with hosts that
> are shut down or somewhere else (laptops)?

Or even how are you going to communicate that there is another machine
of that name? That is a registration and command and control issue in
a completely different 'stack' than the installer usually is in.



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

Re: RFC: Change the default hostname for Fedora 26+

[Adam Williamson]

On Thu, 2016-11-10 at 09:58 -0700, stan wrote:
> On Thu, 10 Nov 2016 11:21:13 -0500
> Stephen John Smoogen  wrote:
> 
> > So in any case, what I am suggesting is that we make a semi-unique
> > identifier. It is unique enough that you won't get a collision in some
> > 'target' space, but not so unique that it stands out like a black dot
> > on a white shirt. Make the code adjustable somewhere in the process so
> > that if someone wants it off, it can be done and if they need it to be
> > a bigger space it can be done so.
> 
> Isn't this pretty trivial to create?  We put a limit on the number of
> machines that are accessible on a local network, say 10 million.  Then
> we start at 
> Fedora-1.localhost.
> e.g.
> 'Fedora-' + str (counter) + '.localhost'
> 
> So if there is only one computer on the local network it is named
> Fedora-1.localhost.
> 
> If there is more than one computer on the local network, we check for
> collisions with names until we hit the next in numerical order that
> isn't taken.
> 
> while name_taken,
>  counter += 1
>  hostname = 'Fedora-' + str (counter) + '.localhost'
>  name_taken = check_for_collision (hostname)
> 
> This ensures there will be *lots* of collisions on the web, but zero
> locally, at least for the first few hosts.
> 
> Or am I missing something?

How exactly are you planning to check for collisions with hosts that
are shut down or somewhere else (laptops)?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Change the default hostname for Fedora 26+

[stan]

On Thu, 10 Nov 2016 11:21:13 -0500
Stephen John Smoogen  wrote:

> So in any case, what I am suggesting is that we make a semi-unique
> identifier. It is unique enough that you won't get a collision in some
> 'target' space, but not so unique that it stands out like a black dot
> on a white shirt. Make the code adjustable somewhere in the process so
> that if someone wants it off, it can be done and if they need it to be
> a bigger space it can be done so.

Isn't this pretty trivial to create?  We put a limit on the number of
machines that are accessible on a local network, say 10 million.  Then
we start at 
Fedora-1.localhost.
e.g.
'Fedora-' + str (counter) + '.localhost'

So if there is only one computer on the local network it is named
Fedora-1.localhost.

If there is more than one computer on the local network, we check for
collisions with names until we hit the next in numerical order that
isn't taken.

while name_taken,
 counter += 1
 hostname = 'Fedora-' + str (counter) + '.localhost'
 name_taken = check_for_collision (hostname)

This ensures there will be *lots* of collisions on the web, but zero
locally, at least for the first few hosts.

Or am I missing something?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM dependency generator ignoring %{_libdir}/pkg/plugin.so

[Tom Hughes]

On 10/11/16 16:47, Stephen Gallagher wrote:

On 11/10/2016 11:44 AM, Tom Hughes wrote:

On 10/11/16 16:41, Richard W.M. Jones wrote:


I'm packaging up a program that puts plugins into

  %{_libdir}/pkg/plugin.so

Unfortunately rpmbuild doesn't seem to generate automatic dependencies
for these files (they are regular ELF files and I have checked that
they contain DT_NEEDED fields).

Any ideas on that?  There's a lot of documentation about how to
exclude files from automatic dep generation, but I want to include
these.


My guess would be that they're not marked as executable. Shared libraries don't
really need to be executable but they always have been in Fedora and the
dependency generator ignores ones which aren't.


It's not just that. Packages that are outside the strict %{_libdir} path aren't
supposed to be automaticatlly generated, since they're assumed to be
package-internal and not exposed to the world.


I think this was requires generation, not provides, which should happen 
everywhere.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM dependency generator ignoring %{_libdir}/pkg/plugin.so

[Richard W.M. Jones]

On Thu, Nov 10, 2016 at 04:44:53PM +, Tom Hughes wrote:
> On 10/11/16 16:41, Richard W.M. Jones wrote:
> 
> >I'm packaging up a program that puts plugins into
> >
> >  %{_libdir}/pkg/plugin.so
> >
> >Unfortunately rpmbuild doesn't seem to generate automatic dependencies
> >for these files (they are regular ELF files and I have checked that
> >they contain DT_NEEDED fields).
> >
> >Any ideas on that?  There's a lot of documentation about how to
> >exclude files from automatic dep generation, but I want to include
> >these.
> 
> My guess would be that they're not marked as executable. Shared
> libraries don't really need to be executable but they always have
> been in Fedora and the dependency generator ignores ones which
> aren't.

Very good catch!  Indeed they were not executable.  I'll see if
setting proper mode fixes things.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM dependency generator ignoring %{_libdir}/pkg/plugin.so

[Stephen Gallagher]

On 11/10/2016 11:44 AM, Tom Hughes wrote:
> On 10/11/16 16:41, Richard W.M. Jones wrote:
> 
>> I'm packaging up a program that puts plugins into
>>
>>   %{_libdir}/pkg/plugin.so
>>
>> Unfortunately rpmbuild doesn't seem to generate automatic dependencies
>> for these files (they are regular ELF files and I have checked that
>> they contain DT_NEEDED fields).
>>
>> Any ideas on that?  There's a lot of documentation about how to
>> exclude files from automatic dep generation, but I want to include
>> these.
> 
> My guess would be that they're not marked as executable. Shared libraries 
> don't
> really need to be executable but they always have been in Fedora and the
> dependency generator ignores ones which aren't.
> 

It's not just that. Packages that are outside the strict %{_libdir} path aren't
supposed to be automaticatlly generated, since they're assumed to be
package-internal and not exposed to the world.




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

Re: RFC: Change the default hostname for Fedora 26+

[Richard W.M. Jones]

On Thu, Nov 10, 2016 at 11:17:20AM +0100, Theodore Papadopoulo wrote:
> On 11/09/2016 02:32 PM, Matthew Miller wrote:
> > On Tue, Nov 08, 2016 at 03:25:58PM -0800, Andrew Lutomirski wrote:
> >> If the hostname is non-constant, can we also arrange that, by default,
> >> this hostname is never sent over the network?  In particular, I think
> >> that DHCP requests should *not* include this hostname.  We're already
> >> starting to randomize MAC addresses -- there's no reason to give a
> >> persistent per-installation identifier to every network.
> > 
> > There's two different cases that I'm not sure how to resolve elegantly.
> > On a home network or on a business network, having the name available
> > is highly desirable. On a public network, just the opposite.
> 
> 
> Add a checkbox in nm so that users can state whether they are on a
> trusted network or not ??

This is what Windows does.

I'm not sure it's a good idea for other reasons - almost no common
network should be "trusted" ...  Should you be sharing your machine
name on your home network that contains some insecure IoT crapware?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RPM dependency generator ignoring %{_libdir}/pkg/plugin.so

[Tom Hughes]

On 10/11/16 16:41, Richard W.M. Jones wrote:


I'm packaging up a program that puts plugins into

  %{_libdir}/pkg/plugin.so

Unfortunately rpmbuild doesn't seem to generate automatic dependencies
for these files (they are regular ELF files and I have checked that
they contain DT_NEEDED fields).

Any ideas on that?  There's a lot of documentation about how to
exclude files from automatic dep generation, but I want to include
these.


My guess would be that they're not marked as executable. Shared 
libraries don't really need to be executable but they always have been 
in Fedora and the dependency generator ignores ones which aren't.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

RPM dependency generator ignoring %{_libdir}/pkg/plugin.so

[Richard W.M. Jones]

I'm packaging up a program that puts plugins into

  %{_libdir}/pkg/plugin.so

Unfortunately rpmbuild doesn't seem to generate automatic dependencies
for these files (they are regular ELF files and I have checked that
they contain DT_NEEDED fields).

Any ideas on that?  There's a lot of documentation about how to
exclude files from automatic dep generation, but I want to include
these.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Change the default hostname for Fedora 26+

[Stephen John Smoogen]

On 10 November 2016 at 10:31, Stephen Gallagher  wrote:
> On 11/10/2016 10:18 AM, Stephen John Smoogen wrote:
>> On 10 November 2016 at 09:27, Stephen Gallagher  wrote:
>>>
> On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
>>
>>
>> Here are the items I would like to point out:
>>
>> 1. The TLD name should be something that DNS considers a known unknown
>> name. With the fact that IANA is allowing top level domains of all
>> sorts we do not want to end up having .fedora  or .foobaz end up
>> causing thousands of computers saying they are in someones domain. So
>> .invalid .localhost .example .local or .test . I expect that
>> .localdomain might not ever be registered but who knows.
>>
>
> RFC 2606[1]  reserves several TLDs that may never be registered for public
> usage. Out of those, going with
> Fedora-.localhost
> seems like the best bet.
>
>
> [1] https://tools.ietf.org/html/rfc2606#page-2
>
>
>> 2. The XX is rather important because of two conflicting items.
>> One we don't want it to be too short that collisions might occur a
>> lot, but we don't want it to be too long for readability but also the
>> less collisions the more likely it can be used to track people. If we
>> don't care about making breadcrumbs which could be used to 'track'
>> people we need to be clear about it so that people who are not wanting
>> that can steer clear. [My 'I am an idiot about randomness' solution
>> would be uuidgen | sum and that number is used for this. There is a
>> good chance of uniqueness per small site and non-uniqueness overall. ]
>>
>
> Again, I think that tracking issues are orthogonal to this ticket. Anyone who
> sets a hostname *manually* is already unique. If that's something to be
> concerned about, then it's better to solve that at whatever layers reveal this
> information.

That is solving it too late because there will always be leaks.
Privacy is just another form of security. If you don't design it in as
best you can early on, you are spending too much work later trying to
patch it in.

Currently hostnames and volumegroups would not be that useful to track
people down. We all like to think that we have come up with that
unique name for the computer.. but in general it isn't that unique and
there are going to be anywhere from 10 to millions of other computers
with that identifier. That actually obscures data and so makes it less
likely to be used.

However anything which is machine created to try and make sure there
aren't easy collisions is a boon to tracking. And any identifier which
may be used in multiple places because it makes it easier on a system
admin or a general program.. bonus. So let us say we don't take this
into consideration until much later or higher in the stack and we want
to make sure that we don't have collisions. So we go with something
like a Fed-<12 char [0-9a-z]> identifier. Because we now have a unique
identifier it tends to get used everywhere that a confusion of names
might occur.. thus vg-<12 char [0-9a-z]> etc.

This makes programmers and system administrators lives easier because
you can have a huge storage array with unique names... yay. However it
also makes the person who has the laptop with Fed-0123456789ab
vg-0123456789ab, etc etc stand out like a sore thumb as various parts
of that data might get leaked out in different places. The hostname
shows up in dhcp logs, the vg shows up in browser environment
variables., some other tools decides that the sys-id is useful for
cookie generation, etc etc. Each time you think you have gotten all
the apps fixed, some programmer finds this unique id, realizes it
makes their life easier for some other problem they have and uses it
again.

So in any case, what I am suggesting is that we make a semi-unique
identifier. It is unique enough that you won't get a collision in some
'target' space, but not so unique that it stands out like a black dot
on a white shirt. Make the code adjustable somewhere in the process so
that if someone wants it off, it can be done and if they need it to be
a bigger space it can be done so.

>
>> 3. case-sensitivity argument about Fedora or fedora looks to be a
>> bikeshed. There are probably local business reasons where having
>> caps/lowercase in names is important but in those cases they should
>> put in tools to conform to their local business reason.
>
> Yeah, I mostly just want Fedora for the proper noun. Since it serves no
> functional difference, I don't care much. After the conversation we've had so
> far, I *do* think we're more or less agreed that we want the longer "Fedora"
> rather than "fed" prefix though.
>
>
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>



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

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

[updates]

The following Fedora EPEL 5 Security updates need testing:
 Age  URL
 732  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-3849   
sblim-sfcb-1.3.8-2.el5
 374  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-edbea40516   
mcollective-2.8.4-1.el5
 346  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-582c8075e6   
thttpd-2.25b-24.el5


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

dpm-dsi-1.9.10-2.el5
globus-authz-3.15-1.el5
globus-common-16.8-1.el5
globus-ftp-client-8.33-1.el5
globus-ftp-control-7.7-1.el5
globus-gass-cache-9.10-1.el5
globus-gass-copy-9.23-1.el5
globus-gatekeeper-10.12-1.el5
globus-gram-audit-4.6-1.el5
globus-gram-client-13.16-1.el5
globus-gram-client-tools-11.10-1.el5
globus-gram-job-manager-14.35-1.el5
globus-gram-job-manager-fork-2.6-1.el5
globus-gram-job-manager-scripts-6.9-1.el5
globus-gram-protocol-12.15-1.el5
globus-gridftp-server-11.8-1.el5
globus-gridmap-eppn-callout-1.13-1.el5
globus-gridmap-verify-myproxy-callout-2.9-1.el5
globus-gsi-callback-5.12-1.el5
globus-gsi-cert-utils-9.15-2.el5
globus-gsi-credential-7.11-1.el5
globus-gsi-openssl-error-3.7-1.el5
globus-gsi-proxy-core-8.6-1.el5
globus-gsi-proxy-ssl-5.10-1.el5
globus-gsi-sysconfig-6.11-1.el5
globus-gss-assist-10.20-1.el5
globus-gssapi-gsi-12.11-1.el5
globus-io-11.8-1.el5
globus-net-manager-0.16-1.el5
globus-openssl-module-4.8-1.el5
globus-proxy-utils-6.18-1.el5
globus-simple-ca-4.24-1.el5
globus-xio-5.14-1.el5
globus-xio-gridftp-driver-2.17-1.el5

Details about builds:



 dpm-dsi-1.9.10-2.el5 (FEDORA-EPEL-2016-4009c7f43e)
 Disk Pool Manager (DPM) plugin for the Globus GridFTP server

Update Information:

Globus Toolkit update.




 globus-authz-3.15-1.el5 (FEDORA-EPEL-2016-4009c7f43e)
 Globus Toolkit - Globus authz library

Update Information:

Globus Toolkit update.




 globus-common-16.8-1.el5 (FEDORA-EPEL-2016-4009c7f43e)
 Globus Toolkit - Common Library

Update Information:

Globus Toolkit update.




 globus-ftp-client-8.33-1.el5 (FEDORA-EPEL-2016-4009c7f43e)
 Globus Toolkit - GridFTP Client Library

Update Information:

Globus Toolkit update.




 globus-ftp-control-7.7-1.el5 (FEDORA-EPEL-2016-4009c7f43e)
 Globus Toolkit - GridFTP Control Library

Update Information:

Globus Toolkit update.




 globus-gass-cache-9.10-1.el5 (FEDORA-EPEL-2016-4009c7f43e)
 Globus Toolkit - Globus Gass Cache

Update Information:

Globus Toolkit update.




 globus-gass-copy-9.23-1.el5 (FEDORA-EPEL-2016-4009c7f43e)
 Globus Toolkit - Globus Gass Copy

Update Information:

Globus Toolkit update.




 globus-gatekeeper-10.12-1.el5 (FEDORA-EPEL-2016-4009c7f43e)
 Globus Toolkit - Globus Gatekeeper

Update Information:

Globus Toolkit update.




 globus-gram-audit-4.6-1.el5 (FEDORA-EPEL-2016-4009c7f43e)
 Globus Toolkit - GRAM Jobmanager Auditing

Urgent call for testing: OS X dual boot

[Adam Williamson]

Hi, folks! We've had an F25 blocker proposed for failure to install as
a dual boot with OS X:

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

is there anyone who has an OS X system they can run this kind of test
on (i.e. one they don't mind getting messed up if something goes
wrong)? We would like more testing data so we can figure out if this is
a system-specific issue or if all OS X dual boot is broken.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora 25-20161110.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 4/101 (x86_64), 2/17 (i386)

New failures (same test did not fail in 25-20161109.n.0):

ID: 47151   Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/47151
ID: 47174   Test: x86_64 KDE-live-iso desktop_browser
URL: https://openqa.fedoraproject.org/tests/47174
ID: 47175   Test: x86_64 KDE-live-iso desktop_notifications_live
URL: https://openqa.fedoraproject.org/tests/47175
ID: 47268   Test: i386 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/47268

Old failures (same test failed in 25-20161109.n.0):

ID: 47266   Test: i386 universal upgrade_2_desktop_32bit
URL: https://openqa.fedoraproject.org/tests/47266
ID: 47270   Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/47270

Passed openQA tests: 89/101 (x86_64), 15/17 (i386), 2/2 (arm)

New passes (same test did not pass in 25-20161109.n.0):

ID: 47162   Test: x86_64 Workstation-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/47162

Skipped openQA tests: 8 of 120
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: rpm vs --compress-debug-sections=zlib

[Tom Hughes]

On 10/11/16 15:25, Vít Ondruch wrote:


This was apparently introduced by upstream commit [2], which adds
"--compress-debug-sections=zlib" as one of linker options. What I
actually don't understand what are the implications of this.

* It seems that RPM cannot handle the compressed debug info properly,
does it also mean that the debuginfo is not stripped?

* Should I ask RPM guys to add support for this?

* Should I remove this flag? Should I ask upstream to make the
compression optional?


I'd say remove it - compressing the debug sections is horrible because 
it forces anything that wants to access the debug data to load it all in 
and decompress it rather than just reading what it needs.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

rpm vs --compress-debug-sections=zlib

[Vít Ondruch]

Hi,

Recently, there have started to appear weird messages in the build
output of development snapshot of Ruby [1]:


```

... snip ...

+ /usr/lib/rpm/find-debuginfo.sh --strict-build-id -m --run-dwz
--dwz-low-mem-die-limit 1000 --dwz-max-die-limit 11000
/builddir/build/BUILD/ruby-2.4.0-r56693

... snip ...

extracting debug info from
/builddir/build/BUILDROOT/ruby-2.4.0-0.1.r56693.fc26.x86_64/usr/lib64/libruby.so.2.4.0
/usr/lib/rpm/debugedit:
/builddir/build/BUILDROOT/ruby-2.4.0-0.1.r56693.fc26.x86_64/usr/lib64/libruby.so.2.4.0:
DWARF version 0 unhandled
extracting debug info from
/builddir/build/BUILDROOT/ruby-2.4.0-0.1.r56693.fc26.x86_64/usr/bin/ruby-mri

... snip ...

dwz: ./usr/lib64/libruby.so.2.4.0.debug: DWARF version 0 unhandled

... snip ...

```


This was apparently introduced by upstream commit [2], which adds
"--compress-debug-sections=zlib" as one of linker options. What I
actually don't understand what are the implications of this.

* It seems that RPM cannot handle the compressed debug info properly,
does it also mean that the debuginfo is not stripped?

* Should I ask RPM guys to add support for this?

* Should I remove this flag? Should I ask upstream to make the
compression optional?


Vít



[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=16383886

[2]
https://github.com/ruby/ruby/commit/a40d95c48fa7e7974feb294abca8af34e299d109

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

[HEADS-UP] PHP 7.1 coming to rawhide next week

[Remi Collet]

Hi,

See: https://fedoraproject.org/wiki/Changes/php71

I plan to build it (7.1.0RC6 which should be the last RC before 7.1.0)
next week.

All extensions should be compatible.
I will take care of the mass rebuild.

I you prefer to build yourself your packages, just drop me an email.



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

Re: RFC: Change the default hostname for Fedora 26+

[Stephen Gallagher]

On 11/10/2016 10:18 AM, Stephen John Smoogen wrote:
> On 10 November 2016 at 09:27, Stephen Gallagher  wrote:
>>
 On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
> 
> 
> Here are the items I would like to point out:
> 
> 1. The TLD name should be something that DNS considers a known unknown
> name. With the fact that IANA is allowing top level domains of all
> sorts we do not want to end up having .fedora  or .foobaz end up
> causing thousands of computers saying they are in someones domain. So
> .invalid .localhost .example .local or .test . I expect that
> .localdomain might not ever be registered but who knows.
> 

RFC 2606[1]  reserves several TLDs that may never be registered for public
usage. Out of those, going with
Fedora-.localhost
seems like the best bet.


[1] https://tools.ietf.org/html/rfc2606#page-2


> 2. The XX is rather important because of two conflicting items.
> One we don't want it to be too short that collisions might occur a
> lot, but we don't want it to be too long for readability but also the
> less collisions the more likely it can be used to track people. If we
> don't care about making breadcrumbs which could be used to 'track'
> people we need to be clear about it so that people who are not wanting
> that can steer clear. [My 'I am an idiot about randomness' solution
> would be uuidgen | sum and that number is used for this. There is a
> good chance of uniqueness per small site and non-uniqueness overall. ]
> 

Again, I think that tracking issues are orthogonal to this ticket. Anyone who
sets a hostname *manually* is already unique. If that's something to be
concerned about, then it's better to solve that at whatever layers reveal this
information.


> 3. case-sensitivity argument about Fedora or fedora looks to be a
> bikeshed. There are probably local business reasons where having
> caps/lowercase in names is important but in those cases they should
> put in tools to conform to their local business reason.

Yeah, I mostly just want Fedora for the proper noun. Since it serves no
functional difference, I don't care much. After the conversation we've had so
far, I *do* think we're more or less agreed that we want the longer "Fedora"
rather than "fed" prefix though.




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

Re: GitPython update blocked by rpkg - how can this be resolved?

[Chenxiong Qi]

On 11/10/2016 09:42 PM, Barry Scott wrote:

In this bug

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

It is implied that rpkg has an unspecified problem with GitPython 2.0.

This is preventing the maintainer from updating to the any GitPython 2
release.

I'd like to know if there is in fact a problem with rpkg with GitPython 2.0.



Import error here.

  File "/root/code/rpkg/pyrpkg/__init__.py", line 14, in 
import git
  File "/root/rpkg-env/lib/python2.6/site-packages/git/__init__.py", 
line 38, in 

from git.config import GitConfigParser  # @NoMove @IgnorePep8
  File "/root/rpkg-env/lib/python2.6/site-packages/git/config.py", line 
25, in 

from git.util import LockFile
  File "/root/rpkg-env/lib/python2.6/site-packages/git/util.py", line 
18, in 

from unittest.case import SkipTest
ImportError: No module named case

GitPython >= 2 cannot work with Python 2.6 at all.


If there is a problem it would be nice if the rpkg people could comment on the
difficult of supporting GitPython 2. The python2.6 support question I suspect
can be handled by version checking in any conflicting code.

It seems wrong that rpkg is blocking updating to the latest GitPython,
preventing user of GitPython getting the bugs fixes and (as far as I am aware)
backwards compatible improvements.

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



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

Re: RFC: Change the default hostname for Fedora 26+

[Stephen John Smoogen]

On 10 November 2016 at 09:27, Stephen Gallagher  wrote:
>
>>> On 11/09/2016 07:27 PM, Stephen Gallagher wrote:


Here are the items I would like to point out:

1. The TLD name should be something that DNS considers a known unknown
name. With the fact that IANA is allowing top level domains of all
sorts we do not want to end up having .fedora  or .foobaz end up
causing thousands of computers saying they are in someones domain. So
.invalid .localhost .example .local or .test . I expect that
.localdomain might not ever be registered but who knows.

2. The XX is rather important because of two conflicting items.
One we don't want it to be too short that collisions might occur a
lot, but we don't want it to be too long for readability but also the
less collisions the more likely it can be used to track people. If we
don't care about making breadcrumbs which could be used to 'track'
people we need to be clear about it so that people who are not wanting
that can steer clear. [My 'I am an idiot about randomness' solution
would be uuidgen | sum and that number is used for this. There is a
good chance of uniqueness per small site and non-uniqueness overall. ]

3. case-sensitivity argument about Fedora or fedora looks to be a
bikeshed. There are probably local business reasons where having
caps/lowercase in names is important but in those cases they should
put in tools to conform to their local business reason.



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

Re: RFC: Change the default hostname for Fedora 26+

[Ms Sanchez]

On 10/11/16 14:08, Roberto Ragusa wrote:


All lower case, please.
Lower case is the default everywhere in Unix, and the hostname also contains
an Internet related meaning, where only lower case is used.




Agree. I prefer lower cases in a hostname.

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

Re: RFC: Change the default hostname for Fedora 26+

[Zbigniew Jędrzejewski-Szmek]

On Thu, Nov 10, 2016 at 09:01:42AM -0500, Stephen Gallagher wrote:
> On 11/10/2016 08:53 AM, Radek Vykydal wrote:
> > 
> > 
> > On 8.11.2016 22:49, Stephen Gallagher wrote:
> >> For as long as I can recall, Fedora has shipped with a default hostname of
> >> "localhost.localdomain"[1]. This default was "safe" for a very long time 
> >> because
> >> we also shipped an /etc/hosts entry that routed this hostname to the 
> >> loopback
> >> device for the benefit of some older system services (like sendmail).
> > 
> > One aspect worth considering is that localhost.localdomain as installer 
> > default
> > means that if hostname is not set by user (in UI or kickstart), transient
> > hostname of installed system would be automatically set during network
> > configuration (by NM) from dhcp or DNS lookup if available (Formerly 
> > anaconda
> > used to set the installed sytem static hostname to hostname obtained from 
> > dhcp
> > or DNS in installation environment but based on a bug report we stopped 
> > doing it).

I don't know the details for other dhcp implementations, but systemd-networkd
will use the dchp-provided "transient" hostname if the "static" hostname is
unset or set to "localhost". Note that this is done dynamically, i.e. the
hostname from dhcp is never stored in /etc/hostname.

> Sorry, Radek. I can't parse that. It sounds like you said that Anaconda does
> automatically set the hostname and then you say you stopped doing that because
> of a bug report. Which one is true for F25/26?

If those other implementations behave like systemd-networkd, then
Radek's comment makes perfect sense ;)

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

Re: RFC: Change the default hostname for Fedora 26+

[Stephen Gallagher]

On 11/10/2016 09:21 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Nov 10, 2016 at 02:08:48PM +0100, Roberto Ragusa wrote:
>> On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
>>> On 11/09/2016 01:03 PM, Richard W.M. Jones wrote:
>>
 Having it CAPS doesn't sound very nice ...

>>>
>>> Yeah, that's fine. I was kind of copying off the windows approach, but I 
>>> really don't care at all whether we present it in lower-case or upper-case 
>>> as long as it's consistent.
>>
>> All lower case, please.
>> Lower case is the default everywhere in Unix, and the hostname also contains
>> an Internet related meaning, where only lower case is used.
> 
> Nah, the internet is case-insensitive. And Fedora is a name, starts with
> a capital letter.


I personally like the idea of the proper name as well, but the Internet is *not*
universally case-insensitive, actually. The scheme and hostname parts must be
case-insensitive[1], but the rest of the URI may be case-sensitive or
case-insensitive at the preference of the web server. Which is terrible, but
reality.


That said, since hostname is permitted to be case-insensitive, I'd like to
support "Fedora-" as the proposed name, because Fedora in our case is a
proper noun (which has specific meaning and emphasis in English, at least). A
fedora is a hat.

Fedora is a way of life :-D



[1] https://tools.ietf.org/html/rfc3986#section-3.2.2




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

Re: RFC: Change the default hostname for Fedora 26+

[Zbigniew Jędrzejewski-Szmek]

On Thu, Nov 10, 2016 at 02:08:48PM +0100, Roberto Ragusa wrote:
> On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
> > On 11/09/2016 01:03 PM, Richard W.M. Jones wrote:
> 
> >> Having it CAPS doesn't sound very nice ...
> >> 
> > 
> > Yeah, that's fine. I was kind of copying off the windows approach, but I 
> > really don't care at all whether we present it in lower-case or upper-case 
> > as long as it's consistent.
> 
> All lower case, please.
> Lower case is the default everywhere in Unix, and the hostname also contains
> an Internet related meaning, where only lower case is used.

Nah, the internet is case-insensitive. And Fedora is a name, starts with
a capital letter.

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

Fedora 25 compose report: 20161110.n.0 changes

[Fedora Branched Report]

OLD: Fedora-25-20161109.n.0
NEW: Fedora-25-20161110.n.0

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

Size of added packages:  0.00 B
Size of dropped packages:2.80 MiB
Size of upgraded packages:   0.00 B
Size of downgraded packages: 0.00 B

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

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =

= DROPPED PACKAGES =
Package: muon-5.5.5-1.fc25
Summary: KDE and Plasma resources management GUI
RPMs:muon muon-discover muon-libs muon-updater
Size:2934356 bytes


= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
Broken deps for armhfp
--
[OmegaT]
OmegaT-2.6.3-2.fc22.armv7hl requires hunspell <= 0:1.4.0
[RackTables]
RackTables-0.20.10-7.fc24.noarch requires php-mysql
[asterisk]
asterisk-dahdi-13.9.1-1.fc25.1.armv7hl requires dahdi-tools >= 0:2.0.0
asterisk-dahdi-13.9.1-1.fc25.1.armv7hl requires libtonezone.so.2.0
[beacon]
beacon-0.5-13.fc24.noarch requires php-mysql
[bionetgen]
bionetgen-2.2.6-3.fc25.armv7hl requires libsundials_cvode.so.1
bionetgen-2.2.6-3.fc25.armv7hl requires libsundials_nvecserial.so.0
[collectd]
collectd-onewire-5.6.0-2.fc25.armv7hl requires libowcapi-3.1.so.0
[golang-github-aws-aws-sdk-go]
golang-github-aws-aws-sdk-go-devel-1.1.3-2.fc25.noarch requires 
golang(golang.org/x/tools/go/types)
[golang-github-gonum-matrix]
golang-github-gonum-matrix-devel-0-0.5.gitfb13962.fc25.noarch requires 
golang(github.com/gonum/lapack/lapack64)
[golang-github-kubernetes-heapster]
golang-github-kubernetes-heapster-devel-0.16.1-4.fc25.noarch requires 
golang(github.com/google/cadvisor/client)
golang-github-kubernetes-heapster-devel-0.16.1-4.fc25.noarch requires 
golang(github.com/google/cadvisor/info/v1)
[golang-github-samalba-dockerclient]
golang-github-samalba-dockerclient-devel-0-0.3.gitc37a52f.fc24.noarch 
requires golang(github.com/docker/docker/pkg/timeutils)
[moksha]
moksha-server-1.0.0-11.fc24.noarch requires orbited
[mrbs]
mrbs-1.4.10-4.fc24.noarch requires php-mysql
[nodejs-co-mocha]
nodejs-co-mocha-1.1.2-1.fc25.noarch requires npm(co) >= 0:4.0.0
[nodejs-cross-spawn]
nodejs-cross-spawn-4.0.0-1.fc25.noarch requires npm(lru-cache) >= 
0:4.0.1
[nodejs-grunt-contrib-csslint]
nodejs-grunt-contrib-csslint-0.4.0-6.fc24.noarch requires 
npm(strip-json-comments) < 0:2
[nodejs-npm-stats]
nodejs-npm-stats-1.1.0-3.fc24.noarch requires npm(JSONStream) < 0:1
[nodejs-rc]
nodejs-rc-1.1.6-2.fc24.noarch requires npm(strip-json-comments) < 0:2
[php-magickwand]
php-magickwand-1.0.9.2-9.fc24.armv7hl requires php(api) = 0:20131106-32
php-magickwand-1.0.9.2-9.fc24.armv7hl requires php(zend-abi) = 
0:20131226-32
[php-pecl-cairo]
php-pecl-cairo-0.3.2-11.fc25.armv7hl requires php(api) = 0:20131106-32
php-pecl-cairo-0.3.2-11.fc25.armv7hl requires php(zend-abi) = 
0:20131226-32
[php-pecl-parsekit]
php-pecl-parsekit-1.3.0-10.fc25.armv7hl requires php(api) = 
0:20131106-32
php-pecl-parsekit-1.3.0-10.fc25.armv7hl requires php(zend-abi) = 
0:20131226-32
[php-pecl-runkit]
php-pecl-runkit-1.0.4-3.fc25.armv7hl requires php(api) = 0:20131106-32
php-pecl-runkit-1.0.4-3.fc25.armv7hl requires php(zend-abi) = 
0:20131226-32
[php-pecl-sphinx]
php-pecl-sphinx-1.3.2-6.fc24.armv7hl requires php(api) = 0:20131106-32
php-pecl-sphinx-1.3.2-6.fc24.armv7hl requires php(zend-abi) = 
0:20131226-32
[poweradmin]
poweradmin-2.1.7-1.fc24.noarch requires php-pear(MDB2_Driver_mysql)
[pyqtrailer]
pyqtrailer-0.6.2-10.fc25.noarch requires pytrailer >= 0:0.6.0
[python-ironicclient]
python3-ironicclient-1.3.1-3.fc25.noarch requires 
python3-openstackclient >= 0:2.1.0
[python-pysaml2]
python3-pysaml2-3.0.2-3.fc25.noarch requires python3-pycrypto >= 0:2.5
[python-zope-i18n]
python2-zope-i18n-4.1.0-4.fc25.noarch requires python2-zope-schema
[qutim]
qutim-0.3.2-5.git.6f3a98a.fc23.armv7hl requires libhunspell-1.3.so.0
[rOCCI-server]
rOCCI-server-1.1.9-1.fc25.noarch requires rubygem(rails) < 0:4.3
rOCCI-server-1.1.9-1.fc25.noarch requires rubygem(responders) < 0:2.2
[redland-bindings]
php-redland-1.0.16.1-16.fc25.armv7hl requires php(api) = 0:20131106-32
php-redland-1.0.16.1-16.fc25.armv7hl requires php(zend-abi) = 
0:20131226-32
[sahana]
sahana-0.6.3-10.fc24.noarch requires php-mysql
[syck]
syck-php-0.70-7.20130402.fc24.armv7hl requires php(api) = 0:20131106-32
syck-php-0.70-7.20130402.fc24.armv7hl requires php(zend-abi) = 
0:20131226-32
[system-config-kickstart]

Re: GitPython update blocked by rpkg - how can this be resolved?

[Dan Horák]

On Thu, 10 Nov 2016 09:07:54 -0500
Josh Boyer  wrote:

> On Thu, Nov 10, 2016 at 8:42 AM, Barry Scott 
> wrote:
> > In this bug
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1360797
> >
> > It is implied that rpkg has an unspecified problem with GitPython
> > 2.0.
> >
> > This is preventing the maintainer from updating to the any
> > GitPython 2 release.
> >
> > I'd like to know if there is in fact a problem with rpkg with
> > GitPython 2.0.
> >
> > If there is a problem it would be nice if the rpkg people could
> > comment on the difficult of supporting GitPython 2. The python2.6
> > support question I suspect can be handled by version checking in
> > any conflicting code.
> >
> > It seems wrong that rpkg is blocking updating to the latest
> > GitPython, preventing user of GitPython getting the bugs fixes and
> > (as far as I am aware) backwards compatible improvements.
> 
> Why does it seem wrong?

yep, a distribution is about compromises, but couldn't a compat
GitPython-1 package solve the problem, if both GitPython 1 and 2 can be
installed in parallel?


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

jplesnik set the koschei monitoring flag of perl-Dancer2 to True

[notifications]

jplesnik set the koschei monitoring flag of perl-Dancer2 to True

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

Re: GitPython update blocked by rpkg - how can this be resolved?

[Josh Boyer]

On Thu, Nov 10, 2016 at 8:42 AM, Barry Scott  wrote:
> In this bug
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1360797
>
> It is implied that rpkg has an unspecified problem with GitPython 2.0.
>
> This is preventing the maintainer from updating to the any GitPython 2
> release.
>
> I'd like to know if there is in fact a problem with rpkg with GitPython 2.0.
>
> If there is a problem it would be nice if the rpkg people could comment on the
> difficult of supporting GitPython 2. The python2.6 support question I suspect
> can be handled by version checking in any conflicting code.
>
> It seems wrong that rpkg is blocking updating to the latest GitPython,
> preventing user of GitPython getting the bugs fixes and (as far as I am aware)
> backwards compatible improvements.

Why does it seem wrong?

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

Re: Broken dependencies: wildfly

[gil]

Hi

a new wildfly release was submitted as update

@ https://bodhi.fedoraproject.org/updates/FEDORA-2016-a04534101f

regards
.g

Il 10/11/2016 14:59, build...@fedoraproject.org ha scritto:

Hiwildfly has broken dependencies in the F-25 tree:
On x86_64:
wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.cxf:cxf-api)
wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.cxf:cxf-rt-core)
wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.ws.security:wss4j)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.hibernate:hibernate-search-infinispan)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.hornetq:hornetq-amqp-protocol)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.infinispan:infinispan-lucene-v3)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.infinispan:infinispan-query)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.jboss.security:jboss-negotiation-net)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.jboss.ws.cxf:jbossws-cxf-resources::wildfly800:)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.jboss.ws.cxf:jbossws-cxf-transports-httpserver)
wildfly-8.1.0-3.fc22.noarch requires mvn(org.opensaml:opensaml)
On i386:
wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.cxf:cxf-api)
wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.cxf:cxf-rt-core)
wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.ws.security:wss4j)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.hibernate:hibernate-search-infinispan)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.hornetq:hornetq-amqp-protocol)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.infinispan:infinispan-lucene-v3)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.infinispan:infinispan-query)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.jboss.security:jboss-negotiation-net)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.jboss.ws.cxf:jbossws-cxf-resources::wildfly800:)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.jboss.ws.cxf:jbossws-cxf-transports-httpserver)
wildfly-8.1.0-3.fc22.noarch requires mvn(org.opensaml:opensaml)
On armhfp:
wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.cxf:cxf-api)
wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.cxf:cxf-rt-core)
wildfly-8.1.0-3.fc22.noarch requires mvn(org.apache.ws.security:wss4j)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.hibernate:hibernate-search-infinispan)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.hornetq:hornetq-amqp-protocol)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.infinispan:infinispan-lucene-v3)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.infinispan:infinispan-query)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.jboss.security:jboss-negotiation-net)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.jboss.ws.cxf:jbossws-cxf-resources::wildfly800:)
wildfly-8.1.0-3.fc22.noarch requires 
mvn(org.jboss.ws.cxf:jbossws-cxf-transports-httpserver)
wildfly-8.1.0-3.fc22.noarch requires mvn(org.opensaml:opensaml)
Please resolve this as soon as possible.




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

Re: RFC: Change the default hostname for Fedora 26+

[Stephen Gallagher]

On 11/10/2016 08:53 AM, Radek Vykydal wrote:
> 
> 
> On 8.11.2016 22:49, Stephen Gallagher wrote:
>> For as long as I can recall, Fedora has shipped with a default hostname of
>> "localhost.localdomain"[1]. This default was "safe" for a very long time 
>> because
>> we also shipped an /etc/hosts entry that routed this hostname to the loopback
>> device for the benefit of some older system services (like sendmail).
> 
> One aspect worth considering is that localhost.localdomain as installer 
> default
> means that if hostname is not set by user (in UI or kickstart), transient
> hostname of installed system would be automatically set during network
> configuration (by NM) from dhcp or DNS lookup if available (Formerly anaconda
> used to set the installed sytem static hostname to hostname obtained from dhcp
> or DNS in installation environment but based on a bug report we stopped doing 
> it).



Sorry, Radek. I can't parse that. It sounds like you said that Anaconda does
automatically set the hostname and then you say you stopped doing that because
of a bug report. Which one is true for F25/26?




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

Re: RFC: Change the default hostname for Fedora 26+

[Radek Vykydal]

On 8.11.2016 22:49, Stephen Gallagher wrote:

For as long as I can recall, Fedora has shipped with a default hostname of
"localhost.localdomain"[1]. This default was "safe" for a very long time because
we also shipped an /etc/hosts entry that routed this hostname to the loopback
device for the benefit of some older system services (like sendmail).


One aspect worth considering is that localhost.localdomain as installer 
default means that if hostname is not set by user (in UI or kickstart), 
transient hostname of installed system would be automatically set during 
network configuration (by NM) from dhcp or DNS lookup if available 
(Formerly anaconda used to set the installed sytem static hostname to 
hostname obtained from dhcp or DNS in installation environment but based 
on a bug report we stopped doing it).


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

GitPython update blocked by rpkg - how can this be resolved?

[Barry Scott]

In this bug

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

It is implied that rpkg has an unspecified problem with GitPython 2.0.

This is preventing the maintainer from updating to the any GitPython 2 
release.

I'd like to know if there is in fact a problem with rpkg with GitPython 2.0.

If there is a problem it would be nice if the rpkg people could comment on the
difficult of supporting GitPython 2. The python2.6 support question I suspect
can be handled by version checking in any conflicting code.

It seems wrong that rpkg is blocking updating to the latest GitPython,
preventing user of GitPython getting the bugs fixes and (as far as I am aware)
backwards compatible improvements.

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

Re: RFC: Change the default hostname for Fedora 26+

[Stephen Gallagher]

On 11/09/2016 08:06 AM, Simo Sorce wrote:
> On Wed, 2016-11-09 at 10:04 +0100, Vít Ondruch wrote:
>> Speaking in "workstation" context, people might realize it is possible
>> to change, but they don't care. My computer is not my pet, I don't need
>> to name it, I couldn't care less. Honestly, it would be better if the
>> hostname was not shown in my terminal by default.
> 
> The hostname is shown, historically, to allow you to understand on which
> machine you are running a command. It is oriented toward a sysadmin
> world, where it is common to log into many machines via telnet/rsh/ssh
> to perform various tasks.
> 
> If we can ship default configurations that show the hostname in PS1 only
> for shells running on a remotely initiated connection and leave the
> prompt to something very short then I think that would work fine. 
> 


Historical reasons aside, part of this discussion was launched because having
something visible in the terminal that reminded a user that they are on Fedora
is of interest from a branding perspective. Since we already have the hostname
displayed there and we've established that defaulting to a static "localhost"
name is less than ideal, it seemed like an easy place to score double points:
fix the hostname problem by selecting a default that would also help with 
branding.

Now, regarding Simo's point: I don't know if it's necessarily something we want
to do by default, but it's definitely possible to accomplish with Powerline[1]
(I know this because that's exactly how I have my system set up today).

If that's something we would legitimately like to add to Workstation by default,
please start a new thread on desk...@lists.fedoraproject.org where it can be
discussed and designed.



[1] https://fedoramagazine.org/add-power-terminal-powerline/



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

Re: RFC: Change the default hostname for Fedora 26+

[Roberto Ragusa]

On 11/09/2016 07:27 PM, Stephen Gallagher wrote:
> On 11/09/2016 01:03 PM, Richard W.M. Jones wrote:

>> Having it CAPS doesn't sound very nice ...
>> 
> 
> Yeah, that's fine. I was kind of copying off the windows approach, but I 
> really don't care at all whether we present it in lower-case or upper-case as 
> long as it's consistent.

All lower case, please.
Lower case is the default everywhere in Unix, and the hostname also contains
an Internet related meaning, where only lower case is used.

-- 
   Roberto Ragusamail at robertoragusa.it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [opensuse-buildservice] introducing new macros across the whole OBS?

[Neal Gompa]

On Thu, Nov 10, 2016 at 7:49 AM, jan matejek  wrote:
> Hello,
> in relation to the python single-spec initiative, I have designed a set
> of new macros that allow significant automation in building Python packages.
>
> However, these are constrained by the %python_module macro used in
> BuildRequires.
> The purpose of this macro is to expand %{python_module foo} to
> python2-foo, python3-foo, etc., based on which python flavors are build
> targets for the package. Obviously, the buildservice itself must be able
> to do this expansion, otherwise it can't resolve the build requirements.
>
> So far I have solved this by placing all the macros in prjconf. But this
> is not viable if I want my macros to be available everywhere. I can
> create a "python-macros" package for all the other macros, and
> buildrequire it, in order to make the packages build in any distro that
> has this package, but I can't do the same for %python_module.
>
> Is it possible to make the buildservice itself recognize this macro, or
> place it in some sort of global prjconf? Ideally without triggering a
> full rebuild of everything?
> Or do you have any tips for alternate solutions?
>
> One thing that occured to me, instead of relying on macros, turn
> "python-foo" packages into metapackages requiring the respective
> "python2-foo", "python3-foo" etc., and then BuildRequire the
> metapackage. I don't have a clear idea about how well this would work,
> it seems rather problematic.
>
> I don't want to make packagers list the buildrequires by hand, because
> the requirements can be numerous and we also want to be able to add more
> python flavors and expand the build requirements accordingly.
>
> thanks for any tips
> m.
>

Why not pull in the dependency generator I upstreamed into RPM[1] into
openSUSE? Fedora is using it now in Fedora 25 and Rawhide[2][3], and
Mageia is using an earlier variant of it now. It establishes common
names for Python packages that provide egg-info or dist-info data
(egg/wheel metadata installed on the system) that can be used for
standardizing how Python dependencies are referenced.

Fedora is currently only using it for Provides generation at the
moment, but Mageia uses it for Provides and Requires generation. That
would make it less onerous in general to package Python stuff, as it
would gain useful dependency generation like Perl and Ruby have. Tools
like pyp2rpm[4] can use these names for generating good spec files
that can build packages properly. Petr Viktorin gave a presentation at
Flock 2016[5][6] about the future of Python packaging in Fedora, with
this as a key staple.

[1]: 
https://github.com/rpm-software-management/rpm/blob/master/scripts/pythondistdeps.py
[2]: http://pkgs.fedoraproject.org/cgit/rpms/rpm.git/tree/
[3]: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/thread/UZ5IZFW7AZVIU3XH6EX4262NVVJRJZUZ/
[4]: https://github.com/fedora-python/pyp2rpm
[5]: https://speakerdeck.com/encukou/python-packaging-in-fedora
[6]: https://www.youtube.com/watch?v=rp5jq-25nZg

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

Re: The 'rpm -q --whatrequires' variant to get list of all dependant packages?

[Stephen Gallagher]

On 11/10/2016 02:08 AM, Pavel Raiskup wrote:
> On Wednesday, November 2, 2016 5:51:51 PM CET Pavel Raiskup wrote:
>> Consider we have package 'foo-libs' that provides set of libraries.
>>
>> How do I get all dependant packages (for batch rebuild of dependencies after
>> package update)?  Something which takes soft dependencies into account, too.
>>
>> Some packages might depend on 'foo-libs' explicitly, some depend on soname
>> (implicitly), some depend on particular file within package (say
>> /usr/libexec/libfoohelper).
>>
>> Is there facility within 'dnf repoquery' that gives ultimate answer?  I can 
>> do
>> sub-queries later do pick the important rebuild candidates.
>>
>> Also, I would be curious about "ultimate" repoquery to get list of SOURCE
>> dependants, e.g. on 'foo-devel'.
> 
> Is there something similar to 'dnf repoquery --whatrequires foo-libs 
> --all-deps'
> in RPM?  See the following:
> 
> $ rpm -q --whatrequires libarchive
> no package requires libarchive
> $ sudo dnf remove libarchive
> Dependencies resolved.
> Error: The operation would result in removing the following protected 
> packages: dnf.


As it happens, as part of our Base Runtime efforts, I've written a tool to do
exactly that (requires DNF 2.0):

dnf update python3-dnf --enablerepo=rawhide
git clone https://github.com/sgallagher/whatpkgs/
cd whatpkgs
./whatpkgs.py neededby [--recommends] foo-libs

(Note: you will probably want to add --hint=glibc-minimal-langpack,
--hint=coreutils and --hint=generic-release[1] to resolve common cases where
more than one package might satisfy a dependency.)



[1] There was a bug in fedora-release in F25 until recently which caused it to
pull in bash and bash's deps. generic-release did not have that bug and is
otherwise identical for this purpose.



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

Re: time to retire some kde4/smoke-based language bindings?

[Petr Pisar]

On 2016-11-10, Peter Robinson  wrote:
> On Wed, Nov 9, 2016 at 5:00 PM, Petr Pisar  wrote:
>> On 2016-11-09, Rex Dieter  wrote:
>>> I was looking at rawhide (ppc64) broken deps, and was reminded of some
>>> pretty old and unmaintained (upstream) kde4/smoke-based language bindings
>>> (csharp, perl, ruby), affected packages include:
>>>
>>> kdebindings
>>> kimono
>>> perl-Qt
>>> ruby-korundum
>>> ruby-qt
>>> smokeqt
>>> smokekde
>>> qyoto
>>>
>> What are their replacements? I.e. how will users write Qt applications
>> in C#, Perl, Ruby after removing those packages?
>
> Presumably their qt5/kde5 equivalents.
>
And they are? I could find only C# binding for Qt5. It seems nothing
exists in Ruby or Perl. Though Ruby has QML binding.

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

[Bug 1393834] New: perl-Algorithm-CurveFit-1.05-17.fc26 FTBFS on ppc64le: Can't call method "element" on an undefined value

[bugzilla]

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

Bug ID: 1393834
   Summary: perl-Algorithm-CurveFit-1.05-17.fc26 FTBFS on ppc64le:
Can't call method "element" on an undefined value
   Product: Fedora
   Version: rawhide
 Component: perl-Algorithm-CurveFit
  Assignee: jples...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org
Blocks: 1051573 (F-ExcludeArch-ppc64le,PPC64LETracker)
   External Bug ID: CPAN 118695



perl-Algorithm-CurveFit-1.05-17.fc26 fails to build on ppc64le:

t/01basic.t .. ok
Can't call method "element" on an undefined value at
/builddir/build/BUILD/Algorithm-CurveFit-1.05/blib/lib/Algorithm/CurveFit.pm
line 217.
# Looks like your test exited with 255 before it could output anything.
t/02bad_deriv.t .. 
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 13/13 subtests


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1051573
[Bug 1051573] ppc64le tracker bug
-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: The 'rpm -q --whatrequires' variant to get list of all dependant packages?

[Pavel Raiskup]

On Thursday, November 10, 2016 11:46:16 AM CET Pádraig Brady wrote:
> On 10/11/16 07:08, Pavel Raiskup wrote:
> > Is there something similar to 'dnf repoquery --whatrequires foo-libs 
> > --all-deps'
> > in RPM?  See the following:
> > 
> > $ rpm -q --whatrequires libarchive
> > no package requires libarchive
> > $ sudo dnf remove libarchive
> > Dependencies resolved.
> > Error: The operation would result in removing the following protected 
> > packages: dnf.
> 
> You can do that with `rpm -e --test`.
> I've a wrapper script for deb and rpm at:
> http://www.pixelbeat.org/scripts/whatrequires

Thanks to everybody for suggestions;  yes those are commands I need.
There's now also rhbz#1393704 to have it implemented in RPM.

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

Re: F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates

[Florian Weimer]

On 11/10/2016 12:49 PM, Neal Gompa wrote:

On Thu, Nov 10, 2016 at 5:30 AM, Jan Kurik  wrote:

but many current Atom-based
devices cannot run Fedora because Fedora does not support their 32-bit
UEFI boot environment.


They *could* if people built 32-bit UEFI loader stuff for it. And
there have been efforts in the past for it. I wouldn't completely rule
this out, though it is uncommon.


Just to be clear, nothing in this change prevents people from booting 
via a 32-bit UEFI environment to run Fedora i686 or x86_64.  For current 
designs (the only ones with UEFI environments), the change should 
provide a slight performance improvement.


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

Re: F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates

[Florian Weimer]

On 11/10/2016 12:42 PM, Alexander Ploumistos wrote:

On Thu, Nov 10, 2016 at 12:30 PM, Jan Kurik  wrote:

* Drop -mtune=atom on i686: This flag was added to improve performance
on the Intel Bonnell microarchitecture.


Would you happen to have a ballpark estimate of the performance cost
that would incur on actual Bonnel CPUs?


Unfortunately not.  I'm not sure which architecture revision could 
provide a reference CPU, and then there is the matter of obtaining 
access to that piece of hardware.


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

Re: F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates

[Neal Gompa]

On Thu, Nov 10, 2016 at 5:30 AM, Jan Kurik  wrote:
> but many current Atom-based
> devices cannot run Fedora because Fedora does not support their 32-bit
> UEFI boot environment.

They *could* if people built 32-bit UEFI loader stuff for it. And
there have been efforts in the past for it. I wouldn't completely rule
this out, though it is uncommon.


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

Re: time to retire some kde4/smoke-based language bindings?

[Peter Robinson]

On Wed, Nov 9, 2016 at 2:42 PM, Rex Dieter  wrote:
> I was looking at rawhide (ppc64) broken deps, and was reminded of some
> pretty old and unmaintained (upstream) kde4/smoke-based language bindings
> (csharp, perl, ruby), affected packages include:
>
> kdebindings
> kimono
> perl-Qt
> ruby-korundum
> ruby-qt
> smokeqt
> smokekde
> qyoto
>
> Of these, I can see *maybe* keeping perl-Qt (and dep smokeqt), primarily
> because it is the only one in this list that's not a leaf package (debconf-
> kde depends on it).
>
> Any comments or objection to orphaning these for f26+ ?

Is qt3 stuff going with them?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: time to retire some kde4/smoke-based language bindings?

[Peter Robinson]

On Wed, Nov 9, 2016 at 5:00 PM, Petr Pisar  wrote:
> On 2016-11-09, Rex Dieter  wrote:
>> I was looking at rawhide (ppc64) broken deps, and was reminded of some
>> pretty old and unmaintained (upstream) kde4/smoke-based language bindings
>> (csharp, perl, ruby), affected packages include:
>>
>> kdebindings
>> kimono
>> perl-Qt
>> ruby-korundum
>> ruby-qt
>> smokeqt
>> smokekde
>> qyoto
>>
> What are their replacements? I.e. how will users write Qt applications
> in C#, Perl, Ruby after removing those packages?

Presumably their qt5/kde5 equivalents.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: The 'rpm -q --whatrequires' variant to get list of all dependant packages?

[Pádraig Brady]

On 10/11/16 07:08, Pavel Raiskup wrote:
> Is there something similar to 'dnf repoquery --whatrequires foo-libs 
> --all-deps'
> in RPM?  See the following:
> 
> $ rpm -q --whatrequires libarchive
> no package requires libarchive
> $ sudo dnf remove libarchive
> Dependencies resolved.
> Error: The operation would result in removing the following protected 
> packages: dnf.

You can do that with `rpm -e --test`.
I've a wrapper script for deb and rpm at:
http://www.pixelbeat.org/scripts/whatrequires
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Perlbal-XS-HTTPHeaders (master). "Build on PowerPC"

[notifications]

From f57944fb11e454eb905feccc91ec4e18b6803133 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Petr=20P=C3=ADsa=C5=99?= 
Date: Thu, 10 Nov 2016 12:39:23 +0100
Subject: Build on PowerPC

---
 perl-Perlbal-XS-HTTPHeaders.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Perlbal-XS-HTTPHeaders.spec b/perl-Perlbal-XS-HTTPHeaders.spec
index d40f299..b5980e6 100644
--- a/perl-Perlbal-XS-HTTPHeaders.spec
+++ b/perl-Perlbal-XS-HTTPHeaders.spec
@@ -1,7 +1,7 @@
 %global libname Perlbal-XS-HTTPHeaders
 Name:   perl-%{libname}
 Version:0.20
-Release:22%{?dist}
+Release:23%{?dist}
 Summary:Perlbal extension for processing HTTP headers
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -65,6 +65,9 @@ make test
 %{_mandir}/man3/Perlbal::XS::HTTPHeaders.*
 
 %changelog
+* Thu Nov 10 2016 Petr Pisar  - 0.20-23
+- Build on PowerPC
+
 * Mon Sep 12 2016 Petr Pisar  - 0.20-22
 - Build on aarch64
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Perlbal-XS-HTTPHeaders.git/commit/?h=master=f57944fb11e454eb905feccc91ec4e18b6803133
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates

[Alexander Ploumistos]

On Thu, Nov 10, 2016 at 12:30 PM, Jan Kurik  wrote:
> * Drop -mtune=atom on i686: This flag was added to improve performance
> on the Intel Bonnell microarchitecture.

Would you happen to have a ballpark estimate of the performance cost
that would incur on actual Bonnel CPUs?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Change the default hostname for Fedora 26+

[Matthew Miller]

On Thu, Nov 10, 2016 at 11:17:20AM +0100, Theodore Papadopoulo wrote:
> Add a checkbox in nm so that users can state whether they are on a
> trusted network or not ??

We have something like this already in Firewall Zones. I think it would
be great to develop that further.

-- 
Matthew Miller

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

F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates

[Jan Kurik]

= Proposed System Wide Change: Fedora 26 C/C++ Compilation Flags Updates =
https://fedoraproject.org/wiki/Changes/Fedora26CFlags

Change owner(s):
* Florian Weimer 

This change updates the default C/C++ compilation flags, as determined
by the redhat-rpm-config package.



== Detailed Description ==
This change covers the following modifications to the default C and
C++ compiler flags in the redhat-rpm-config package.

* Drop -mtune=atom on i686: This flag was added to improve performance
on the Intel Bonnell microarchitecture. Such CPUs are rare these days.
In addition, many users of the i686 packages download them for use
within a 64-bit x86_64 installation, and only a small part of these
Fedora installations use Atom CPUs. Current microarchitectures for
Atom CPUs are different from the original Bonnell microarchtecture and
would need different GCC flags for tuning, but many current Atom-based
devices cannot run Fedora because Fedora does not support their 32-bit
UEFI boot environment.
* Add -Werror=implicit-function-declaration: Implicit function
declarations allows a programmer to call functions without declaring
them (or including the relevant header files). The official C language
specification has not supported implicit function declarations for
almost two decades now. GCC still supports them as a GNU extension.
Implicit function declarations introduce bugs because these functions
use a different calling convention and have a fixed return type of
int. Resulting issues are pointer truncation (on 64-bit
architectures), exposure of padding bits (particular for
bool-returning functions on x86_64), and unexpected lack of hardening.
Implicit function declarations are not part of C++ (with or without
GNU extensions), and adjusting C code accordingly simplifies reuse in
C++ projects.
* Add -Werror=implicit-int: Implicit ints were removed from the C
programming language at the same time as implicit function
definitions, and were also retained as a GNU extension. Implicit ints
are usually source code bugs, and the presence of such code may
interfere with future C language directions (for example, consider how
C++ reused the auto keyword and an omitted type specifier).

The main risk from these changes are incorrect autoconf feature
checks, which often rely on technically invalid C fragments. However,
a review of existing configure scripts did not find any places where
they relied on these two problematic GNU extensions.

The technical side of this change is tracked in bug 1393492.



== Scope ==
* Proposal owners: The defaults in redhat-rpm-config need to be
changed, as described above.

* Other developers: Source code which relies on implicit function
declarations or implicit ints needs to be adjusted.

* Release engineering: This change requires a mass rebuild to become
fully effective.

* List of deliverables: No release blocking deliverables.

* Policies and guidelines: no changes proposed (change will be
implemented through redhat-rpm-config)

* Trademark approval: N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F26 System Wide Change: Fedora 26 C/C++ Compilation Flags Updates

[Jan Kurik]

= Proposed System Wide Change: Fedora 26 C/C++ Compilation Flags Updates =
https://fedoraproject.org/wiki/Changes/Fedora26CFlags

Change owner(s):
* Florian Weimer 

This change updates the default C/C++ compilation flags, as determined
by the redhat-rpm-config package.



== Detailed Description ==
This change covers the following modifications to the default C and
C++ compiler flags in the redhat-rpm-config package.

* Drop -mtune=atom on i686: This flag was added to improve performance
on the Intel Bonnell microarchitecture. Such CPUs are rare these days.
In addition, many users of the i686 packages download them for use
within a 64-bit x86_64 installation, and only a small part of these
Fedora installations use Atom CPUs. Current microarchitectures for
Atom CPUs are different from the original Bonnell microarchtecture and
would need different GCC flags for tuning, but many current Atom-based
devices cannot run Fedora because Fedora does not support their 32-bit
UEFI boot environment.
* Add -Werror=implicit-function-declaration: Implicit function
declarations allows a programmer to call functions without declaring
them (or including the relevant header files). The official C language
specification has not supported implicit function declarations for
almost two decades now. GCC still supports them as a GNU extension.
Implicit function declarations introduce bugs because these functions
use a different calling convention and have a fixed return type of
int. Resulting issues are pointer truncation (on 64-bit
architectures), exposure of padding bits (particular for
bool-returning functions on x86_64), and unexpected lack of hardening.
Implicit function declarations are not part of C++ (with or without
GNU extensions), and adjusting C code accordingly simplifies reuse in
C++ projects.
* Add -Werror=implicit-int: Implicit ints were removed from the C
programming language at the same time as implicit function
definitions, and were also retained as a GNU extension. Implicit ints
are usually source code bugs, and the presence of such code may
interfere with future C language directions (for example, consider how
C++ reused the auto keyword and an omitted type specifier).

The main risk from these changes are incorrect autoconf feature
checks, which often rely on technically invalid C fragments. However,
a review of existing configure scripts did not find any places where
they relied on these two problematic GNU extensions.

The technical side of this change is tracked in bug 1393492.



== Scope ==
* Proposal owners: The defaults in redhat-rpm-config need to be
changed, as described above.

* Other developers: Source code which relies on implicit function
declarations or implicit ints needs to be adjusted.

* Release engineering: This change requires a mass rebuild to become
fully effective.

* List of deliverables: No release blocking deliverables.

* Policies and guidelines: no changes proposed (change will be
implemented through redhat-rpm-config)

* Trademark approval: N/A (not needed for this Change)
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 RC 1.2 compose check report

[Adam Williamson]

On Thu, 2016-11-10 at 01:43 +, Fedora compose checker wrote:
> No missing expected images.
> 
> Failed openQA tests: 2/101 (x86_64), 3/17 (i386)
> 
> New failures (same test did not fail in 25 RC 1.1):
> 
> ID: 47037 Test: i386 Workstation-live-iso install_default
> URL: https://openqa.fedoraproject.org/tests/47037

Something crashed again. i686 does seem very crashy.

> ID: 47124 Test: x86_64 universal install_european_language
> URL: https://openqa.fedoraproject.org/tests/47124
> ID: 47125 Test: x86_64 universal install_cyrillic_language
> URL: https://openqa.fedoraproject.org/tests/47125

These were some kind of transient issue, I re-ran the tests and they
passed. Also passed fine on staging.

> ID: 47138 Test: i386 universal upgrade_desktop_32bit
> URL: https://openqa.fedoraproject.org/tests/47138

Repo issue, re-ran and it worked.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org