Re: Enabling "-Werror=format-security" by default

[Alexander Bokovoy]

On Wed, 20 Nov 2013, Dhiru Kholia wrote:

Hi,

We are working on a proposal to enable "-Werror=format-security"
compilation flag for all packages in Fedora.

Once this flag is enabled, GCC will refuse to compile code that could be
vulnerable to a string format security flaw. For more details, please
see https://fedorahosted.org/fesco/ticket/1185 page.

Enabling this option eliminates an entire class of security issues! To
further understand why it is important to fix such bugs, please see
https://fedoraproject.org/wiki/Format-Security-FAQ page.

Currently, around 400 packages FTBFS if this flag is enabled. I am all
set to start filing the bugs (once given the green signal). In addition,
I am willing to help in patching these packages. I believe that this
work is important and will benefit everyone (including upstream and
other distributions).

I am attaching a sample Bugzilla bug report - this is what the actual
bug reports will look like.

I think these reports are misleading, at least in FreeIPA case.
freeipa-3.3.1-2.fc21.src.rpm/build.log:ipa_enrollment.c:320:5: error: format 
not a string literal and no format arguments [-Werror=format-security]
freeipa-3.3.1-2.fc21.src.rpm/build.log:ipa_enrollment.c:347:9: error: format 
not a string literal and no format arguments [-Werror=format-security]
freeipa-3.3.1-2.fc21.src.rpm/build.log:ipa_enrollment.c:360:5: error: format 
not a string literal and no format arguments [-Werror=format-security]

All three cases are dealing with following lines:
   LOG("%s", errMesg ? errMesg : "success\n");
   LOG("%s", errMesg);
   LOG("%s", errMesg);

where LOG macro expands to 
   slapi_log_error(SLAPI_LOG_PLUGIN, NAME, format, arguments ... );


(SLAPI_LOG_PLUGIN and NAME are constants)

as you can see, in all these cases format *is* a string literal and
there are exact format arguments passed.

--
/ Alexander Bokovoy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora 20 TC2 AMIs

[Dennis Gilmore]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

Final TC2 images have been uploaded to EC2 and are available at 

ami-3392b55a : us-east-1 image for i386
ami-f794b39e : us-east-1 image for x86_64

additionally if your looking to the AMI's they have been added to files
in the release tree
http://dl.fedoraproject.org/pub/alt/stage/20-TC2/Images/i386/Fedora-Images-i386-20-TC2-AMI
http://dl.fedoraproject.org/pub/alt/stage/20-TC2/Images/x86_64/Fedora-Images-x86_64-20-TC2-AMI

when we get to final and the images are uploaded to all regions
they will all be listed and the file will be gpg signed in the final
tree

Dennis
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJSjZC/AAoJEH7ltONmPFDREnQP/2y5fb33v+9yBxJ6pq0waKN1
KNOTAebB0dRkM5FAZJ70RqywQgwwrvPf77MM61cXto07mjm7/ZCyZ8gnVIyHAftd
RzmTALL2sbTVapubGnN1klheXfTrR30Ht7GD5XiNicuJ/4MQ/akW1TJoRbqbOnpB
YoP6mY8c+3TDMrETSc18GRS303nzHTsrmHygDlswBdkkSj9kGv5dRqwU7zE0uSUn
QJm373KrlxEiWiLKmYJJXbsr3QrcHJ7EBG/vGvo+wux+tywx34+gAdgFDhcV2Q/0
YLz4S112gTqoDMWQM6f2/nmqeGZSonl+fRrxH/oJIp25khA0GhTmVke+ztmfODHT
95i1Xx6VuHNYcRFUkblkVsOkwAIFVch2ISLqNw5kLK64ti1A8vkgjVmMesuVbJNf
JrMkU/CcwyCMD0gC1w/ReQDMU5VIdiIGyovV2V+jolQq28UL8TgQnd9xc51ZO28i
IIHUOoboyDqCXbIcqTDCiWhuYjdqcAO9JcX7WvoQr6hWawgDmRtVtC4CCbZusSyL
13oK4xfienacnVVPGhcDOJ2wsSCbN0qmByx1HcKatkgw7g/likYhUe5INBVSu+2F
lrJ8SUs3C31gu4uIeHRx7+79hI3d3naqAYI9KeSMWco2EoSOkhO0+KTco53IcEJV
7B+7SemC2u4zvWLFU8uH
=uaFs
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Test-Announce] Fedora 20 Final Test Compose 2 (TC2) Available Now!

[Andre Robatino]

NOTE: The 64-bit LXDE Live is over its size limit.

As per the Fedora 20 schedule [1], Fedora 20 Final Test Compose 2 (TC2)
is now available for testing. Content information, including changes,
can be found at https://fedorahosted.org/rel-eng/ticket/5808#comment:6 .
Please see the following pages for download links (including delta ISOs)
and testing instructions. Normally dl.fedoraproject.org should provide
the fastest download, but download-ib01.fedoraproject.org is available
as a mirror (with an approximately 1 hour lag) in case of trouble. To
use it, just replace "dl" with "download-ib01" in the download URL.

Installation:

https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Base:

https://fedoraproject.org/wiki/Test_Results:Current_Base_Test

Desktop:

https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test

Ideally, all Alpha, Beta, and Final priority test cases for Installation
[2], Base [3], and Desktop [4] should pass in order to meet the Final
Release Criteria [5]. Help is available on #fedora-qa on
irc.freenode.net [6], or on the test list [7].

Create Fedora 20 Final test compose (TC) and release candidate (RC)
https://fedorahosted.org/rel-eng/ticket/5808

Current Blocker and Freeze Exception bugs:
http://qa.fedoraproject.org/blockerbugs/current

[1] http://fedorapeople.org/groups/schedule/f-20/f-20-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[3] https://fedoraproject.org/wiki/QA:Base_validation_testing
[4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing
[5] https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria
[6] irc://irc.freenode.net/fedora-qa
[7] https://admin.fedoraproject.org/mailman/listinfo/test



signature.asc
Description: OpenPGP digital signature
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Headless Java

[Aleksandar Kurtakov]

- Original Message -
> From: "Toshio Kuratomi" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, November 20, 2013 11:46:32 PM
> Subject: Re: F21 System Wide Change: Headless Java
> 
> On Wed, Nov 20, 2013 at 01:39:48PM -0500, Aleksandar Kurtakov wrote:
> > 
> > The thing is this is pointless. If the people that would do most of this
> > auditing (Java SIG) do not agree with such scenario the result would be
> > that old Require:java will be kept whenever full java jvm is used as this
> > keeps compatibility, ease of cooperation with other distros and so on.
> 
> In fedora we do our best to figure out what the best course of action is and
> then we execute that.  This often involves constructive criticism where
> people raise potential issues and then everyone looks for ways to address
> those issues.
> 
> So if I'm reading this right, what you want to enable is for people to
> install the third-party provided jdk and uninstall the Fedora OpenJDK and
> then be able to install their Fedora application packages on that
> environment.  In order for that to be done without the Fedora OpenJDK being
> dragged in, the idea is that the application packages can only Require:
> things that are also provided by these third party packages.  The third
> party packages already have a virual provide for java and a virtual provide
> for java-headless.  They do not have a virtual provide for
> java-x11/gui/equivalent.
> 
> Is that correct?

No. What I want most is Fedora srpms to stay usable for Mageia/Mandriva guys to 
import them and build in their build systems.
They do have their own jvm builds which I never cared about as we collaborate 
pretty well on the things sitting on top of the JVM.
So no, I do not want to let people install other JVMs and use them on Fedora I 
speak about SRPMs and rebuilding them here.

> 
> Note that in the past, Fedora policy has been that Fedora does not control
> what and how third parties package so it's usually not a good idea to write
> packages to accomodate things in third party repos if it keeps Fedora from
> making better packages.  But with that in mind, there's two angles that we
> can work on to show that accomodating third party packages is a good idea in
> this case.
> 
> Angle 1) more information about the costs of the second virtual provide:
>   - Do you have links to the third party jdk packages that are providing
> java-headless and java  and not providing java-x11/gui/etc?  Are we
> talking about a few alternate jdks or many?  or just the most important
> one (The one from Oracle)?  This would help to show how widely the
> virtual provides will affect other packages.
>   - Do you have some information about how many people are uninstalling
> Fedora's openjdk package and installing these alternate jdk packages in
> their place?  This would help to show how widely people are actually
> going to be inconvenienced by the difference in virtual provides.
> 
> Angle 2) Reduce the benefits of the second virtual provide
>   - Propose alternate means of tracking what packages have been audited and
> found to actually need full java.
> - If the target is mainly new maintainers of the package in question,
>   then Requiring that Requires: java have a comment in the spec file to
>   say that the package really does need the graphical portions of java
>   to be installed may be sufficient.
> - If the target is to keep an updated list of what packages are yet to
>   be audited, propose something like Virtual Provide in the packages
>   that depend on java.  So if you have java-foo that Requires: java and
>   you have audited the package to know that the requirement is real, add
>   Provides: java-x11-needed to the package.  Then scripts can take the
>   set of packages that Require java and do not Provide java-x11-needed
>   to generate an up to date list.

The more important question to me is why this needs to be tracked? Tracking and 
collecting information that noone looks at is pointless. 
I opened FE-JAVASIG bug long ago hoping that people will help us fight issue, 
it doesn't happen. 
Now the two angles are kind of irrelevant with me not looking to switch openjdk 
in fedora and not planning to look into such tracking information. 
Tracker bugs don't mean anything, it's goals that people set themselves - and 
I'm yet to meet anyone else but 2-3 guys that ever package java and think about 
the whole java ecosystem and not about their own tiny bit. It doesn't have to 
be perfect, it's better to be as simple as possible so one can get maximum 
result ASAP and move to proper solution (which java-headless is not at all - 
it's just a workaround). 
Honestly, I don't think any auditing will happen at all. It's maven and wildfly 
maintainers that will go and fix stuff here and there to get their packages 
work in headless environment and that's it.

Alexander Kurtakov
Red Hat Eclipse

AutoQA and Beaker Downtime Today

[Tim Flink]

Apologies for the late notice, I had the wrong date in my head for this.

With the Fedora Infrastructure outage today, I'm going to take the
opportunity to update and reboot all the AutoQA and Beaker
infrastructure.

AutoQA and Beaker will be mostly down for about 3 hours from 22:00 UTC.

I'll send out another email when everything is back up and running.

Tim



signature.asc
Description: PGP signature
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: F21 System Wide Change: Headless Java

[Toshio Kuratomi]

On Wed, Nov 20, 2013 at 01:39:48PM -0500, Aleksandar Kurtakov wrote:
> 
> The thing is this is pointless. If the people that would do most of this
> auditing (Java SIG) do not agree with such scenario the result would be
> that old Require:java will be kept whenever full java jvm is used as this
> keeps compatibility, ease of cooperation with other distros and so on.

In fedora we do our best to figure out what the best course of action is and
then we execute that.  This often involves constructive criticism where
people raise potential issues and then everyone looks for ways to address
those issues.

So if I'm reading this right, what you want to enable is for people to
install the third-party provided jdk and uninstall the Fedora OpenJDK and
then be able to install their Fedora application packages on that
environment.  In order for that to be done without the Fedora OpenJDK being
dragged in, the idea is that the application packages can only Require:
things that are also provided by these third party packages.  The third
party packages already have a virual provide for java and a virtual provide
for java-headless.  They do not have a virtual provide for
java-x11/gui/equivalent.

Is that correct?

Note that in the past, Fedora policy has been that Fedora does not control
what and how third parties package so it's usually not a good idea to write
packages to accomodate things in third party repos if it keeps Fedora from
making better packages.  But with that in mind, there's two angles that we
can work on to show that accomodating third party packages is a good idea in
this case.

Angle 1) more information about the costs of the second virtual provide:
  - Do you have links to the third party jdk packages that are providing
java-headless and java  and not providing java-x11/gui/etc?  Are we
talking about a few alternate jdks or many?  or just the most important
one (The one from Oracle)?  This would help to show how widely the
virtual provides will affect other packages.
  - Do you have some information about how many people are uninstalling
Fedora's openjdk package and installing these alternate jdk packages in
their place?  This would help to show how widely people are actually
going to be inconvenienced by the difference in virtual provides.

Angle 2) Reduce the benefits of the second virtual provide
  - Propose alternate means of tracking what packages have been audited and
found to actually need full java.
- If the target is mainly new maintainers of the package in question,
  then Requiring that Requires: java have a comment in the spec file to
  say that the package really does need the graphical portions of java
  to be installed may be sufficient.
- If the target is to keep an updated list of what packages are yet to
  be audited, propose something like Virtual Provide in the packages
  that depend on java.  So if you have java-foo that Requires: java and
  you have audited the package to know that the requirement is real, add
  Provides: java-x11-needed to the package.  Then scripts can take the
  set of packages that Require java and do not Provide java-x11-needed
  to generate an up to date list.

-Toshio


pgpRrm1tW2yvK.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Source file audit - 2013-11-17

[Ville Skyttä]

On Wed, Nov 20, 2013 at 6:44 PM, Till Maas  wrote:
> On Wed, Nov 20, 2013 at 11:50:17AM +0200, Ville Skyttä wrote:
>
>> I think I'll make spectool tell curl not to verify SSL certs by
>> default in the next release. If you want it already now for your local
>> spectool, do for example this: "echo --insecure >>
>> /etc/rpmdevtools/curlrc"
>
> IMHO the default should be to check certificates

I kind of guessed you'd disagree here as you didn't like the patch I
added to cnucnu disabling the certificate check :)

BTW IMNSHO the certificate check should still be disabled in cnucnu as
well. I don't think it makes sense to fail the entire purpose of the
tool (to notify people who have subscribed to notifications about
updates) because of certificate check failures (and in a silent way so
that the subscribers will probably never know).

> especially since
> spectool is the usual tool to update source files in dist-git. Only if
> there is no need to check the certificate, this should be disabled.

I don't think there's any need for the connection where publicly
available sources are fetched from without supplying any credentials
to be encrypted in the first place. Checking the downloaded content
matters, and that has nothing to do with whether the certificate of
the transfer connection is expired or not or if it's issued by a
trusted party or not or if it passes common name/hostname checks.
spectool is not a source verification tool nor a certificate
validation one, and I'm not going to help people get the misconception
that it might be something like that.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enabling "-Werror=format-security" by default

[Dan Winship]

On 11/20/2013 11:13 AM, Jerry James wrote:

And the very first package I maintain that appears on that list, abe,
is an interesting one.  The game has an internal function,
path_sprintf(), which is static in Game.c.  All callers of that
function are visible in the same file, and all pass constant strings
into the function, which passes those constant strings to sprintf().
The function's purpose is to produce a pathname for a file of interest
to the caller in the game's installed location.  It's too bad that
gcc's analysis cannot span function calls inside a compilation unit.
There really is nothing wrong with this code.


If you change its prototype to:

static void path_sprintf (char *path, char *format, ...) 
__attribute__((__format__(__printf, 2, 3)));


(and update it to use varargs and vsprintf() instead of sprintf())

then the warnings will go away, because gcc will now know that it's a 
function that behaves like printf(), with argument 2 being the format 
string and argument 3 being the "...", and so then it can do the 
-Wformat-security checking at each of the path_sprintf() callpoints. 
(And you also get warnings when the arguments don't match the format 
string, like you would if you were calling sprintf() directly.) (And now 
you can use formats other than a single "%d" in the future if you want...)


-- Dan

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enabling "-Werror=format-security" by default

[Mark Wielaard]

On Wed, 2013-11-20 at 23:15 +0530, Dhiru Kholia wrote:
> On 11/20/13 at 11:16am, David Smith wrote:
> > > On 11/20/13 at 09:27pm, Dhiru Kholia wrote:
> > > A list of packages which FTBFS is available at,
> > >
> > > http://people.fedoraproject.org/~halfie/rebuild-logs.txt
> >
> > Looking at the list, I see several (~17) packages with errors of the form:
> >
> > error: -Wformat-security ignored without -Wformat [-Werror=format-security]
> >
> > Which is an error, but not exactly what you are trying to catch. Got any
> > ideas on what is going on here?
> 
> Hi David,
> 
> Excellent catch! I took a quick look and it seems that these packages
> are trying to use custom compilation flags.
> 
> E.g. p0f-3.06b-3.fc20.src.rpm has a line which says,
> 
> BASIC_CFLAGS="-Wall -Wno-format -I/usr/local/include/ \
>   -I/opt/local/include/ -DVERSION=\"$VERSION\" $CFLAGS"
> 
> 
> The usage of hard-coded "-Wno-format" flag conflicts with our desired
> "-Werror=format-security" flag.
> [...]
> The very next project I am (and was) planning to work on, is to detect
> packages which try to use custom compilation flags ;)

elfutils seems to be in somewhat of the same situation, although
slightly different. Upstream does actually explicitly enable -Werror
-Wformat=2 for all files, but has 5 exceptions for which it uses
-Wno-format which then clashes with the setting of -Wformat-security.

The reason such files use -Wno-format is either because they have some
helper method such as:

ssize_t
regtype (const char *setname, int type, const char *fmt, int arg)
{
   [...]
   int s = snprintf (name, namelen, fmt, arg);

which is always called with a static fmt string, but gcc is unable to
detect that.

Or it contains code that creates a format string such as by:

/* Location print format string.  */
static const char *locfmt;

[...]

parse_opt()

  switch (arg[0])
{
case 'd':
  locfmt = "%7" PRId64 " ";
  break;

case 'o':
octfmt:
  locfmt = "%7" PRIo64 " ";
  break;

case 'x':
  locfmt = "%7" PRIx64 " ";
  break;

default:
  error (0, 0, gettext ("invalid value '%s' ...

[...]

process()
  if (unlikely (locfmt != NULL))
printf (locfmt, (int64_t) to - len - (buf - start));

Where gcc again seems unable to detect that the locfmt string is a
constant string.

How to deal with such cases?

Thanks,

Mark

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Wednesday's FESCo Meeting (2013-11-20)

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

===
#fedora-meeting: FESCO (2013-11-20)
===


Meeting started by sgallagh at 17:59:37 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting/2013-11-20/fesco.2013-11-20-17.59.log.html
.



Meeting summary
- ---
* init process  (sgallagh, 17:59:47)

* #1193 reboots for all updates -- are we ready for this?  (sgallagh,
  18:02:13)
  * ACTION: mattdm to contact the Change owner to update the wiki page
and release notes  (sgallagh, 18:04:29)

* #1185 Enable "-Werror=format-security" by default  (sgallagh,
  18:04:43)
  * 400 packages fail rebuild  (mattdm, 18:06:56)
  * AGREED: 1) wait a week for devel feedback (from people already
interested); 2) if there are no show-stoppers identified, mass file
bugs; 3) 3 weeks later, enable in rawhide configuration by default
(+8, 0, -0)  (sgallagh, 18:14:50)
  * AGREED: Please file a Change page for this. (+7, 0, 0)  (sgallagh,
18:17:44)

* #1198 Possible changes to Fedora EOL bug procedure  (sgallagh,
  18:18:08)
  * AGREED: Ask the Bugzilla administrators to implement the
reopen-and-re-version request (+8, 0, -0)  (sgallagh, 18:20:21)

* #1140 F20 Self Contained Changes - week 2013-07-10 - 2013-07-17
  (sgallagh, 18:20:52)
  * LINK: http://fedoraproject.org/wiki/Features/Java8TechPreview and
"ibus-gnome3 is provided in a ibus subpackage as a technology
preview for Fedora 16." are some older examples.  (nirik, 18:26:07)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1024144   (adamw,
18:33:16)
  * LINK:

https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&component=anaconda&component=lvm&component=lvm2&component=python-blivet&list_id=1922711&query_format=advanced&short_desc=thin&short_desc_type=allwordssubstr
is a quick sesarch i just came up with for anaconda, blivet and lvm
bugs with 'thin' in the summary  (adamw, 18:46:38)
  * LINK: http://fedoraproject.org/wiki/Features/Java8TechPreview
(mattdm, 18:46:45)
  * AGREED: leave the decision of whether to hide or fix thinp to
anaconda.  We're also okay with QA's interpretation of the criteria
which may lead to release slippage if some thinp bugs are considered
blockers (+7, 0 -0)  (sgallagh, 18:52:07)

* #1205 Workstation WG governance charter  (sgallagh, 18:52:28)
  * AGREED: Workstation Governance Document is approved (+9, 0, -0)
(sgallagh, 18:54:51)

* #1203 Soft dependencies  (sgallagh, 18:57:27)
  * AGREED: FESCo would be OK with some implementations of soft
dependencies. To get a more clear ACK or NAK, come up with an
implementation design (+7, 0, -1)  (sgallagh, 19:08:57)

* #1202 Release and Support lifecycle questions  (sgallagh, 19:09:04)
  * AGREED: If working groups want to use different cycles, they should
provide us with what they want to do with rationale along with the
PRD.  They should be aware that even if we can okay the plan, it is
unlikely to be implementable for one or more releases. Please do not
make your PRD depend on an alternate release lifecycle. (+7, 0, -1)
(sgallagh, 19:38:14)

* #1206 Allowed licenses in Copr  (sgallagh, 19:39:07)
  * AGREED: COPR projects must use approved Fedora licenses for now (+6,
0, -1)  (sgallagh, 19:46:38)

* #1204 F21 System Wide Change: Python 3.4
  -https://fedoraproject.org/wiki/Changes/Python_3.4  (sgallagh,
  19:46:59)
  * AGREED: Python 3.4 Change is approved (+8, 0, -0)  (sgallagh,
19:49:34)

* #1201 Enabling third party repositories  (sgallagh, 19:50:20)
  * AGREED: Defer to the next FESCo meeting and ask further questions in
the ticket for clarification.  (sgallagh, 19:58:43)

* Next week's chair  (sgallagh, 19:58:49)
  * mmaslano to chair the next meeting  (sgallagh, 19:59:28)

* Open Floor  (sgallagh, 20:00:51)

Meeting ended at 20:03:21 UTC.




Action Items
- 
* mattdm to contact the Change owner to update the wiki page and release
  notes




Action Items, by person
- ---
* mattdm
  * mattdm to contact the Change owner to update the wiki page and
release notes
* **UNASSIGNED**
  * (none)




People Present (lines said)
- ---
* sgallagh (187)
* nirik (87)
* abadger1999 (82)
* mitr (71)
* mattdm (70)
* pjones (63)
* notting (50)
* t8m (41)
* adamw (32)
* mmaslano (26)
* jreznik (22)
* jwb (19)
* zodbot (17)
* Viking-Ice (12)
* dlehman (8)
* kparal (5)
* drago01 (3)
* iThinkDev (3)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKNIYwACgkQeiVVYja6o6M2JQCfZhXP70TnhCTSPsAlf/hS2Df6
XtsAoIo3gpKXE/Cr52T3StidLdQRiZJf
=Oy+B
-END

Bundled md5 in OCaml

[Richard W.M. Jones]

See:
https://github.com/ocaml/ocaml/blob/trunk/byterun/md5.c#L78

(1) In terms of the bundled(md5-$IMPLEMENTATION), which
$IMPLEMENTATION is this?

(2) Ideally I would like to replace this with a call to a library (in
Fedora, I don't think this would be accepted upstream).  But which
library should I use?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Headless Java

[Aleksandar Kurtakov]

- Original Message -
> From: "Toshio Kuratomi" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, November 20, 2013 9:23:29 PM
> Subject: Re: F21 System Wide Change: Headless Java
> 
> On Wed, Nov 20, 2013 at 08:13:02PM +0100, Marcela Mašláňová wrote:
> > 
> > We were speaking about giving more power to SIGs related to
> > discussion about Fedora.next. This can be a good start. Stano and
> > Aleksandar are working on Java maintenance a lot, Java SIG members
> > are speaking together, so I have a confidence in their actions.
> > 
> This is a tangent but -- some people have been talking about giving more
> power to SIGs but at the last env and stacks meeting we sorta settled on
> more power to SIGs in an experimental, anything-goes repo.  We're not
> tlaking about that here.

I have no idea what was discussed at these meetings but the thing is if such 
thing would happen it would only happen if we do it - history has proved that 
changes don't happen magically by themself. If one is forced to do something he 
doesn't think is the correct he would not do it and if the Java SIG doesn't 
step in to drive this change we all lose. While something might sound as the 
better engineered solution it doesn't matter if it "burns bridges" to other 
communities and I do care for e.g. Mageia developers as they do better than our 
mass-rebuilds as problems they find often come back to us even with a patch. 
Not to mention that simply concentrating on what I would call a "temporary 
solution" is a mistake too and as such should be done with minimal changes. 
Modularizing and naming will come from the OpenJDK upstream in Java 8 to some 
extend(Compact Profiles). If such a thing happens to be such a problem and lose 
time discussing things that are proved to not work who would even dare to try 
pushing them into Fedora. If upstream OpenJDK has a "headless" mode - inventing 
new name will break the stay close to upstream, if well established project 
like Debian calls the same thing "headless" - we reduce chances to share and 
collaboration as we end up people explaining what does x11 and what does 
headless mean in conversation, if this is a subject of a change soon - why not 
let current maintainers do it as they want and get involved into helping get 
the profiles. For me this is implementation detail, which gives nothing but bad 
feeling into current maintainers as people involved into the actual work 
already agreed on the solution - not perfect but the most acceptable one.

Alexander Kurtakov
Red Hat Eclipse team

> 
> -Toshio
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Headless Java

[Toshio Kuratomi]

On Wed, Nov 20, 2013 at 08:13:02PM +0100, Marcela Mašláňová wrote:
> 
> We were speaking about giving more power to SIGs related to
> discussion about Fedora.next. This can be a good start. Stano and
> Aleksandar are working on Java maintenance a lot, Java SIG members
> are speaking together, so I have a confidence in their actions.
> 
This is a tangent but -- some people have been talking about giving more
power to SIGs but at the last env and stacks meeting we sorta settled on
more power to SIGs in an experimental, anything-goes repo.  We're not
tlaking about that here.

-Toshio


pgpbCg7FMFRnW.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Headless Java

[Marcela Mašláňová]

On 20/11/13 18:53, Toshio Kuratomi wrote:

On Wed, Nov 20, 2013 at 12:27:38PM -0500, Aleksandar Kurtakov wrote:

I start to think this conversation goes nowhere. The whole split is
superficial and most java developers are used to get full jvm if they
require java.  This would probably change with Java 8 introducing Profiles
[1]. And any proper packaging should be modeled after this one. Inventing
even more new names/provided/etc. now would just increase the mess we
already have.  I remember seeing servlets using awt/ImageIO for image
processing on tomcat version running on headless server - and it was
leading just to jvm crash. That was in Java 5 times but illustrates the
problem. This was easily fixable by adding -Djava.awt.headless=true to
Tomcat startup scripts, what I want to point with that is that simply
moving a package require java-headless from full java has to be carefully
thought on per package base with some changes done to the packages if
needed to ensure no such bad examples start to pop out. Java means full
JVM so we would better not confuse this with any java-x11(what about
wayland coming?) or similar naming at least for now. Also headless(through
the java.awt.headless option) is known and well recognized option in Java
community while x11 would mean nothing to many Java developers. This keeps
us closer to common terms and not deviate needlessly.


And nothing changes the term "java" 's meaning for developers or users...
The several proposals only add the new term, java-x11 for packagers and
even there, they allow for deprecation, they do not break backwards compat.
Third parties can continue to use Requires: java.  Unaudited code in Fedora
will continue to use Requires: java.  Only when someone has spent the time
to check whether a package will work with headless and determined that it
will not will the package change its Require: to java-x11 (or similar) to
record for future maintainers and other interested parties that the package
cannot be used without the full jvm.

-Toshio



I must agree with Aleksandar, this discussion is going nowhere. There 
weren't mentioned any valid arguments, why to do Wide Change differently 
than proposed by the Change owner.


We were speaking about giving more power to SIGs related to discussion 
about Fedora.next. This can be a good start. Stano and Aleksandar are 
working on Java maintenance a lot, Java SIG members are speaking 
together, so I have a confidence in their actions.


Marcela
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Headless Java

[Aleksandar Kurtakov]

- Original Message -
> From: "Toshio Kuratomi" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, November 20, 2013 7:53:15 PM
> Subject: Re: F21 System Wide Change: Headless Java
> 
> On Wed, Nov 20, 2013 at 12:27:38PM -0500, Aleksandar Kurtakov wrote:
> > I start to think this conversation goes nowhere. The whole split is
> > superficial and most java developers are used to get full jvm if they
> > require java.  This would probably change with Java 8 introducing Profiles
> > [1]. And any proper packaging should be modeled after this one. Inventing
> > even more new names/provided/etc. now would just increase the mess we
> > already have.  I remember seeing servlets using awt/ImageIO for image
> > processing on tomcat version running on headless server - and it was
> > leading just to jvm crash. That was in Java 5 times but illustrates the
> > problem. This was easily fixable by adding -Djava.awt.headless=true to
> > Tomcat startup scripts, what I want to point with that is that simply
> > moving a package require java-headless from full java has to be carefully
> > thought on per package base with some changes done to the packages if
> > needed to ensure no such bad examples start to pop out. Java means full
> > JVM so we would better not confuse this with any java-x11(what about
> > wayland coming?) or similar naming at least for now. Also headless(through
> > the java.awt.headless option) is known and well recognized option in Java
> > community while x11 would mean nothing to many Java developers. This keeps
> > us closer to common terms and not deviate needlessly.
> > 
> And nothing changes the term "java" 's meaning for developers or users...
> The several proposals only add the new term, java-x11 for packagers and
> even there, they allow for deprecation, they do not break backwards compat.
> Third parties can continue to use Requires: java.  Unaudited code in Fedora
> will continue to use Requires: java.  Only when someone has spent the time
> to check whether a package will work with headless and determined that it
> will not will the package change its Require: to java-x11 (or similar) to
> record for future maintainers and other interested parties that the package
> cannot be used without the full jvm.

The thing is this is pointless. If the people that would do most of this 
auditing (Java SIG) do not agree with such scenario the result would be that 
old Require:java will be kept whenever full java jvm is used as this keeps 
compatibility, ease of cooperation with other distros and so on. I for one 
would not introduce requires to some virtual provide that would break 
compatibility with other JVMs in my packages even after auditing it. And we end 
up with one more unused virtual provide on top of all the other which were 
added with such good intentions and end up just clutter the situation. If you 
look at openjdk spec you'll see provides like - jre, java-fonts, jndi, 
java-sasl and so on and they are simply not used. 
They were introduced for various reasons but their usage is the same today - 
none. Let's not make the same mistake one more time.

Alexander Kurtakov
Red Hat Eclipse team

> 
> -Toshio
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-Tree-Simple/f20] Upstream update.

[corsepiu]

Summary of changes:

  aaea3f3... Upstream update. (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: F21 System Wide Change: Headless Java

[Toshio Kuratomi]

On Wed, Nov 20, 2013 at 12:27:38PM -0500, Aleksandar Kurtakov wrote:
> I start to think this conversation goes nowhere. The whole split is
> superficial and most java developers are used to get full jvm if they
> require java.  This would probably change with Java 8 introducing Profiles
> [1]. And any proper packaging should be modeled after this one. Inventing
> even more new names/provided/etc. now would just increase the mess we
> already have.  I remember seeing servlets using awt/ImageIO for image
> processing on tomcat version running on headless server - and it was
> leading just to jvm crash. That was in Java 5 times but illustrates the
> problem. This was easily fixable by adding -Djava.awt.headless=true to
> Tomcat startup scripts, what I want to point with that is that simply
> moving a package require java-headless from full java has to be carefully
> thought on per package base with some changes done to the packages if
> needed to ensure no such bad examples start to pop out. Java means full
> JVM so we would better not confuse this with any java-x11(what about
> wayland coming?) or similar naming at least for now. Also headless(through
> the java.awt.headless option) is known and well recognized option in Java
> community while x11 would mean nothing to many Java developers. This keeps
> us closer to common terms and not deviate needlessly.
> 
And nothing changes the term "java" 's meaning for developers or users...
The several proposals only add the new term, java-x11 for packagers and
even there, they allow for deprecation, they do not break backwards compat.
Third parties can continue to use Requires: java.  Unaudited code in Fedora
will continue to use Requires: java.  Only when someone has spent the time
to check whether a package will work with headless and determined that it
will not will the package change its Require: to java-x11 (or similar) to
record for future maintainers and other interested parties that the package
cannot be used without the full jvm.

-Toshio


pgpVwa3yQbmYM.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enabling "-Werror=format-security" by default

[Dhiru Kholia]

On 11/20/13 at 11:16am, David Smith wrote:
> > On 11/20/13 at 09:27pm, Dhiru Kholia wrote:
> > A list of packages which FTBFS is available at,
> >
> > http://people.fedoraproject.org/~halfie/rebuild-logs.txt
>
> Looking at the list, I see several (~17) packages with errors of the form:
>
> error: -Wformat-security ignored without -Wformat [-Werror=format-security]
>
> Which is an error, but not exactly what you are trying to catch. Got any
> ideas on what is going on here?

Hi David,

Excellent catch! I took a quick look and it seems that these packages
are trying to use custom compilation flags.

E.g. p0f-3.06b-3.fc20.src.rpm has a line which says,

BASIC_CFLAGS="-Wall -Wno-format -I/usr/local/include/ \
  -I/opt/local/include/ -DVERSION=\"$VERSION\" $CFLAGS"


The usage of hard-coded "-Wno-format" flag conflicts with our desired
"-Werror=format-security" flag. p0f is a "security package" and it
should know better, I believe.

Additionally, p0f packaging seems to be violating the Fedora packaging
guidelines,

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

The very next project I am (and was) planning to work on, is to detect
packages which try to use custom compilation flags ;)

--
Dhiru
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Schedule for Thursday's FPC Meeting (2013-11-21 17:00 UTC)

[James Antill]

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

 Local time information (via. rktime):

2013-11-21 09:00 Thu US/Pacific PST
2013-11-21 12:00 Thu US/Eastern EST
2013-11-21 17:00 Thu UTC <-
2013-11-21 17:00 Thu Europe/London <-
2013-11-21 18:00 Thu Europe/Paris   CET
2013-11-21 18:00 Thu Europe/Berlin  CET
2013-11-21 22:30 Thu Asia/Calcutta  IST
--new day--
2013-11-22 01:00 Fri Asia/Singapore SGT
2013-11-22 01:00 Fri Asia/Hong_Kong HKT
2013-11-22 02:00 Fri Asia/Tokyo JST
2013-11-22 03:00 Fri Australia/Brisbane EST

 Links to all tickets below can be found at: 

https://fedorahosted.org/fpc/report/12

= Followups =

(approval and retirement sections already passed)
#topic #339 software collections in Fedora
.fpc 339
https://fedorahosted.org/fpc/ticket/339

= New business =

#topic #358 Please make some autotools guidelines.
.fpc 358
https://fedorahosted.org/fpc/ticket/358

#topic #359 Guideline: Forbid sysv initscripts in addition to
systemd unit files
.fpc 359
https://fedorahosted.org/fpc/ticket/359

#topic #361 Two more bundled MD5 implementations
.fpc 361
https://fedorahosted.org/fpc/ticket/361

#topic #362 lpf should not be allowed in Fedora
.fpc NNN
https://fedorahosted.org/fpc/ticket/NNN

#topic #363 exception for bundled library libntirpc in nfs-ganesha
.fpc NNN
https://fedorahosted.org/fpc/ticket/NNN

#topic #364 exception for bundled library ccan in ocserv
.fpc 364
https://fedorahosted.org/fpc/ticket/364

#topic #367 Another bundled MD5 implementation originally by Ulrich Drepper
.fpc NNN
https://fedorahosted.org/fpc/ticket/NNN

= Open Floor = 

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

https://fedorahosted.org/fpc/report/12


 If you would like to add something to this agenda, you can reply to
this e-mail, file a new ticket at https://fedorahosted.org/fpc,
e-mail me directly, or bring it up at the end of the meeting, during
the open floor topic. Note that added topics may be deferred until
the following meeting. 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enabling "-Werror=format-security" by default

[Przemek Klosowski]

On 11/20/2013 11:13 AM, Jerry James wrote:
path_sprintf(), which is static in Game.c. All callers of that 
function are visible in the same file, and all pass constant strings 
into the function, which passes those constant strings to sprintf(). 
The function's purpose is to produce a pathname for a file of interest 
to the caller in the game's installed location. It's too bad that 
gcc's analysis cannot span function calls inside a compilation unit. 
There really is nothing wrong with this code. 

Well, the code is inelegant:

 sprintf(path + len, formatted_name);

looks better and avoids the warning if you write it as

 sprintf(&(path[len]), "%s", formatted_name);

which should lead the reader to reflect on whether it makes sense to prevent 
buffer overflow by
using %NNs to limit the size of appended name so that it fits within the limits 
of the path buffer.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[389-devel] Please review: Ticket #47478 No groups file? error restarting Admin server

[Rich Megginson]

https://fedorahosted.org/389/attachment/ticket/47478/0001-Ticket-47478-No-groups-file-error-restarting-Admin-s.patch
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: Schedule for Wednesday's FESCo Meeting (2013-11-20)

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/19/2013 12:55 PM, Stephen Gallagher wrote:
> Following is the list of topics that will be discussed in the
> FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on
> irc.freenode.net.
> 
> To convert UTC to your local time, take a look at 
> http://fedoraproject.org/wiki/UTCHowto
> 
> or run: date -d '-MM-DD HH:MM UTC'
> 
> 


Just to summarize: here's the (very) full agenda for today's meeting:

#startmeeting FESCO (2013-11-20)
#meetingname fesco
#chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh
#topic init process

= Followups =

#topic #1193 reboots for all updates -- are we ready for this?
.fesco 1193
https://fedorahosted.org/fesco/ticket/1193

#topic #1185 Enable "-Werror=format-security" by default
.fesco 1185
https://fedorahosted.org/fesco/ticket/1185

#topic #1198 Possible changes to Fedora EOL bug procedure
.fesco 1198
https://fedorahosted.org/fesco/ticket/1198

#topic #1140 F20 Self Contained Changes - week 2013-07-10 - 2013-07-17
.fesco 1140
https://fedorahosted.org/fesco/ticket/1140

= New business =

#topic #1205 Workstation WG governance charter
.fesco 1205
https://fedorahosted.org/fesco/ticket/1205

#topic #1203 Soft dependencies
.fesco 1203
https://fedorahosted.org/fesco/ticket/1203

#topic #1202 Release and Support lifecycle questions
.fesco 1202
https://fedorahosted.org/fesco/ticket/1202

#topic #1206 Allowed licenses in Copr
.fesco 1206
https://fedorahosted.org/fesco/ticket/1206

#topic #1204 F21 System Wide Change: Python 3.4 -
https://fedoraproject.org/wiki/Changes/Python_3.4
.fesco 1204
https://fedorahosted.org/fesco/ticket/1204

#topic #1201 Enabling third party repositories
.fesco 1201
https://fedorahosted.org/fesco/ticket/1201


#topic Next week's chair
#topic Open Floor
#endmeeting
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKM9WwACgkQeiVVYja6o6PARQCeK3YRFhzN3ZZ7FFrZdxTdg15g
DT4AmwWkmLc0gZS9F8s2p+fYb8ywG9cq
=dNvP
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[389-devel] Please review: Ticket #434 admin-serv logs filling with "admserv_host_ip_check: ap_get_remote_host could not resolve "

[Rich Megginson]

https://fedorahosted.org/389/attachment/ticket/434/0001-Ticket-434-admin-serv-logs-filling-with-admserv_host.patch
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel

Re: Enabling "-Werror=format-security" by default

[Till Maas]

On Wed, Nov 20, 2013 at 10:21:10PM +0530, Dhiru Kholia wrote:
> On 11/20/13 at 09:27pm, Dhiru Kholia wrote:
> > We are working on a proposal to enable "-Werror=format-security"
> > compilation flag for all packages in Fedora.
> >
> > Currently, around 400 packages FTBFS if this flag is enabled.
> 
> A list of packages which FTBFS is available at,
> 
> http://people.fedoraproject.org/~halfie/rebuild-logs.txt

Here is a list with owners of affected packages:
http://till.fedorapeople.org/tmp/format-security-owners.txt

It was created as follows:
curl http://people.fedoraproject.org/~halfie/rebuild-logs.txt | cut -d/ -f1 | 
rev | cut -d- -f 3-  | rev  | sort -u | fedoradev-pkgowners | sort

Regards
Till
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-Tree-Simple] Upstream update.

[corsepiu]

commit aaea3f3a1151f27b2ad363e2e5b5be02b3c66b59
Author: Ralf Corsépius 
Date:   Wed Nov 20 18:41:24 2013 +0100

Upstream update.

- BR: perl(Test::Version).

 .gitignore|2 +-
 perl-Tree-Simple.spec |7 ++-
 sources   |2 +-
 3 files changed, 8 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 755b936..b6e8ff2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-/Tree-Simple-1.22.tgz
+/Tree-Simple-1.23.tgz
diff --git a/perl-Tree-Simple.spec b/perl-Tree-Simple.spec
index 3806170..26a0436 100644
--- a/perl-Tree-Simple.spec
+++ b/perl-Tree-Simple.spec
@@ -1,5 +1,5 @@
 Name:  perl-Tree-Simple
-Version:   1.22
+Version:   1.23
 Release:   1%{?dist}
 Summary:   Tree::Simple Perl module
 License:   GPL+ or Artistic
@@ -13,6 +13,7 @@ BuildRequires:  perl(Scalar::Util) >= 1.18
 BuildRequires:  perl(Test::Exception) >= 0.15 
 BuildRequires:  perl(Test::More) >= 0.47
 BuildRequires:  perl(Test::Memory::Cycle)
+BuildRequires:  perl(Test::Version) >= 1.002003
 
 Requires:  perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 
@@ -41,6 +42,10 @@ make test
 %{_mandir}/man3/*
 
 %changelog
+* Wed Nov 20 2013 Ralf Corsépius  - 1.23-1
+- Upstream update.
+- BR: perl(Test::Version).
+
 * Mon Sep 30 2013 Ralf Corsépius  - 1.22-1
 - Upstream update.
 
diff --git a/sources b/sources
index 61539e5..3e5fae1 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ac81e94af7f4e84517ae0ef72f14a852  Tree-Simple-1.22.tgz
+827b2d3d9d7c876aa92fcc7357ecf348  Tree-Simple-1.23.tgz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: F21 System Wide Change: Headless Java

[Aleksandar Kurtakov]

I start to think this conversation goes nowhere. The whole split is superficial 
and most java developers are used to get full jvm if they require java.
This would probably change with Java 8 introducing Profiles [1]. And any proper 
packaging should be modeled after this one. Inventing even more new 
names/provided/etc. now would just increase the mess we already have. 
I remember seeing servlets using awt/ImageIO for image processing on tomcat 
version running on headless server - and it was leading just to jvm crash. That 
was in Java 5 times but illustrates the problem. This was easily fixable by 
adding -Djava.awt.headless=true to Tomcat startup scripts, what I want to point 
with that is that simply moving a package require java-headless from full java 
has to be carefully thought on per package base with some changes done to the 
packages if needed to ensure no such bad examples start to pop out. Java means 
full JVM so we would better not confuse this with any java-x11(what about 
wayland coming?) or similar naming at least for now. Also headless(through the 
java.awt.headless option) is known and well recognized option in Java community 
while x11 would mean nothing to many Java developers. This keeps us closer to 
common terms and not deviate needlessly.


[1] http://openjdk.java.net/jeps/161


Alexander Kurtakov
Red Hat Eclipse team

- Original Message -
> From: "Toshio Kuratomi" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, November 20, 2013 7:10:56 PM
> Subject: Re: F21 System Wide Change: Headless Java
> 
> On Wed, Nov 20, 2013 at 03:04:16PM +0100, Stanislav Ochotnicky wrote:
> > 
> > So which one of them would "Provides: java"? I'll give you several
> > variants:
> > 
> > headless provides java:
> > - breaks compatibility expectations of older/3rd party RPMs
> > - we suddenly switch every Java package in Fedora. No opt-out
> > 
> > meta package provides java (and requires both headless and x11 version):
> > - doesn't change anything because you can't "yum remove java-meta" or
> > "yum
> >   remove java-x11" (due to packages having "requires: java" which is
> >   satisfied by this metapackage.  And no, packages cannot have
> >   "Requires:
> >   java-1.7.0-openjdk[-meta]" because there are usually multiple
> >   implementations of java in Fedora. We'd be changing buildrequires
> >   every
> >   few releases.
> > 
> > x11 version provides java:
> > - That's basically what current proposal is with addition of
> > metapackage.
> >   But I fail to see the point of metapackage in this scenario
> > 
> The meta package should provide java.  I actually think that the meta
> package providing java is closest to what the current proposal is minus the
> metapackage.  Unless I'm misunderstanding the current proposal, as long as
> packages Require: java but could really just need headless then there is no
> change from the status quo.  It isn't until packagers modify their Requires
> to java-headless that we see benefits.  So the benefit arrives at the same
> time as it would with a metapackage.
> 
> Note -- If I'm reading you right and then remembering the trickiness of the
> multiple-jdk's The Provides: java may be the equivalent of the
> metapackage currently.  What's really missing is a Provides: java-x11 type
> package.  That way packagers can mark that their package really does require
> the gui bits.
> 
> > 
> > Then again I might be completely missing the point of the metapackage but
> > I've
> > been trying for past day (on and off) to come up with situation where it
> > would
> > help without causing multiple other issues (or at least backward
> > incompatibility) and failed... So if you can explain it, or give a better
> > example how you think it should work: I'd love to be wrong.
> > 
> > > > I can see one advantage to this approach: it lets us tell packagers
> > > > that
> > > > Requires: java should no longer be used.
> > 
> > I don't consider that an advantage. It breaks backward compatibility
> > for...I
> > don't know. I don't mind Fedora being different. But if we diverge from
> > conventions it would be great to have a *good* reason.
> > 
> It doesn't break any backwards compatibility.  It gives us a deprecation
> route.  ie: Requires: java works but we're telling people not to use it.
> 
> > > > Packagers should determine whether
> > > > they're using APIs that require X and either Requires: java-x11 or
> > > > Requires:
> > > > java-headless based on what they really need.  We can then audit the
> > > > packageset at a later date to determine which packages haven't adjusted
> > > > their Requirements yet
> > 
> > So what is stopping us from auditing the package set with current non-x11
> > proposal? There will be bugzillas, it will be easy to see which packages
> > were
> > automatically converted to headless, which were supposedly fixed by their
> > maintainers and then just go through th

EPEL Fedora 6 updates-testing report

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 577  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6
  91  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11274/ssmtp-2.61-21.el6
  52  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11703/chicken-4.8.0.4-4.el6
  33  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11865/quassel-0.9.1-1.el6
  16  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12025/seamonkey-2.22-1.el6
  11  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12064/drupal7-context-3.1-1.el6
   6  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12079/bip-0.8.9-1.el6
   5  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12040/python-djblets-0.7.23-1.el6,ReviewBoard-1.7.18-1.el6
   5  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12102/moodle-2.4.7-1.el6
   0  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12156/varnish-2.1.5-5.el6
   0  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12154/mediawiki119-1.19.9-1.el6


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

erlang-R14B-04.3.el6
glacier-cli-0-7.20131113gite8a2536.el6
mMass-5.5.0-5.el6
mediawiki119-1.19.9-1.el6
php-extras-5.3.3-2.el6
salt-0.17.2-1.el6
salt-0.17.2-2.el6
varnish-2.1.5-5.el6
wondershaper-1.2.1-2.el6
xrootd-3.3.4-1.el6

Details about builds:



 erlang-R14B-04.3.el6 (FEDORA-EPEL-2013-12148)
 General-purpose programming language and runtime environment

Update Information:

fix crash on ppc64

ChangeLog:

* Tue Nov 19 2013 Dan Horák  - R14B-04.3
- Fix segfault due memory corruption when reading topology info (#958953)

References:

  [ 1 ] Bug #958953 - erlang-R14B-04.2.el6.ppc64 segfaults on RHEL6.4
https://bugzilla.redhat.com/show_bug.cgi?id=958953




 glacier-cli-0-7.20131113gite8a2536.el6 (FEDORA-EPEL-2013-12147)
 Command-line interface to Amazon Glacier

Update Information:

new package

References:

  [ 1 ] Bug #1031019 - Review Request: glacier-cli - Command-line interface to 
Amazon Glacier
https://bugzilla.redhat.com/show_bug.cgi?id=1031019




 mMass-5.5.0-5.el6 (FEDORA-EPEL-2013-12151)
 Open Source Mass Spectrometry Tool

Update Information:

Lipid Maps Database update.

ChangeLog:

* Tue Nov 19 2013 Antonio Trande  5.5.0-5
- Update LIPID MAPS Database (November 16, 2013)
- User Guide packaged in the .doc subpackage
- Installed new .desktop file




 mediawiki119-1.19.9-1.el6 (FEDORA-EPEL-2013-12154)
 A wiki engine

Update Information:

Update to upstream 1.19.9.


- (bug 53032) SECURITY: Don't cache when a call could autocreate
- (bug 55332) SECURITY: Improve css javascript detection
- (bug 49717) Fix behaviour $wgVerifyMimeType = false; in Upload
Translations

ChangeLog:

* Wed Nov 20 2013 Patrick Uiterwijk  - 1.19.9-1
- Update to 1.19.9

References:

  [ 1 ] Bug #1030987 - CVE-2013-4567 CVE-2013-4568 CVE-2013-4572 mediawiki: 
security releases 1.21.3, 1.20.8, and 1.19.9
https://bugzilla.redhat.com/show_bug.cgi?id=1030987




 php-extras-5.3.3-2.el6 (FEDORA-EPEL-2013-12145)
 Additional PHP modules from the standard PHP distribution

Update Information:

Drop tidy (provided now by the main php packages).

Some little cleanups and bug fixes.
---

EPEL Fedora 5 updates-testing report

[updates]

The following Fedora EPEL 5 Security updates need testing:
 Age  URL
 577  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5
  91  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11276/ssmtp-2.61-21.el5
  67  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5
  31  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5
  11  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12067/drupal7-context-3.1-1.el5
   6  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12091/bip-0.8.9-1.el5
   0  
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12157/varnish-2.0.6-4.el5


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

salt-0.17.2-1.el5
salt-0.17.2-2.el5
varnish-2.0.6-4.el5
xrootd-3.3.4-1.el5

Details about builds:



 salt-0.17.2-1.el5 (FEDORA-EPEL-2013-12152)
 A parallel remote execution system

Update Information:

Updated to bugfix release 0.17.2.

ChangeLog:

* Mon Nov 18 2013 Erik Johnson  - 0.17.2-1
- Update to bugfix release 0.17.2




 salt-0.17.2-2.el5 (FEDORA-EPEL-2013-12146)
 A parallel remote execution system

Update Information:

Patched to fix pkgrepo.managed regression.

ChangeLog:

* Tue Nov 19 2013 Erik Johnson  - 0.17.2-2
- Patched to fix pkgrepo.managed regression
* Mon Nov 18 2013 Erik Johnson  - 0.17.2-1
- Update to bugfix release 0.17.2




 varnish-2.0.6-4.el5 (FEDORA-EPEL-2013-12157)
 High-performance HTTP accelerator

Update Information:

Backported a patch for CVE-2013-4484

ChangeLog:

* Wed Nov  6 2013 Ingvar Hagelund  - 2.0.6-4
- Added a patch to logrotate config, closes #554745
- Backported a patch for CVE-2013-4484, closes #1025129
* Tue Oct 26 2010 Ingvar Hagelund  - 2.0.6-3
- Build fixes for ppc
- Added a patch for v6.vtc that tames a malloc bonanza in some cases

References:

  [ 1 ] Bug #1025129 - CVE-2013-4484 varnish: denial of service handling 
certain GET requests [epel-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1025129




 xrootd-3.3.4-1.el5 (FEDORA-EPEL-2013-12158)
 Extended ROOT file server

Update Information:

xrootd release 3.3.4

Major bug fixes
* Serialize sss authentication client initialization to prevent race conditions
* Actually cancel the JobManager threads while stopping it - this affected 
client side fork handling (new client)
* Restore original meaning of -adler and -md5 to xrdcp

Minor bug fixes
* Append CGI info when retrying at a server that handshaked but never respnded 
to the request (xrdcp)
* Do socket accepts asynchronously to prevent DNS resolution from blocking 
accepts
* Warn about incomplete dirlist responses (xrdfs)
* Cast the utilization statistics to uint16_t before printing to print actual 
numbers instead of letters corresponding to ASCII codes (xrdfs)

Miscellaneous
* When calling File::Stat use file handle instead of path
* Improve handling of malformed kXR_readv responses (new client)
* Explain parameters of xrdcopy --tpc (documentation)


ChangeLog:

* Tue Nov 19 2013 Mattias Ellert  - 1:3.3.4-1
- Update to version 3.3.4
* Sun Aug  4 2013 Fedora Release Engineering  
- 1:3.3.3-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild


___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: ExcludeArch being ignored when building spring f20.

[Gilboa Davara]

On Wed, Nov 20, 2013 at 5:55 PM, Dan Horák  wrote:
> On Wed, 20 Nov 2013 17:23:33 +0200
> Gilboa Davara  wrote:
>
>> Hello all,
>>
>> I'm facing a weird issue when trying to build a new version of spring.
>> First and foremost, the spring.spec has "ExcludeArch:ppc ppc64
>> %{arm}", which should exclude arm* and ppc* (both not supported by
>> upstream).
>
> also a question is whether you should rather do ExclusiveArch: %[ix86}
> x86_64 because there are other arches in Fedora like s390 or aarch64
> which are very likely also unsupported

Good idea. I'll issue new specs.

- Gilboa
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Using git for patch management in Fedora

[Alek Paunov]

On 20.11.2013 11:19, Richard W.M. Jones wrote:

On Tue, Nov 19, 2013 at 03:36:54PM -0800, Toshio Kuratomi wrote:

One note though, I think that in the past one of the discussion points we've
foundered on is whether we want to be mirroring upstream's git repo or
(approximately) upstream's releases.  I think that's probably where we'd
need to start discussion.



From the point of view of patch management, I have a strong view here:


We should be mirroring upstream's git, if they have one.

The reason is that it makes it trivial to cherry pick upstream patches
on top of the Fedora branch.

So I'd arrange it by having a straight mirror of upstream, then have
our own 'fNN-branch' branches which contain the upstream releases
(ideally from upstream tags if they are using git sensibly) + our
cherry picked patches.



What you (and Daniel yesterday, and Karel, and ... likely everybody) 
clarifying is the natural scheme:


fsource:
 XYZ:
  XYZ[ref1]:
   fNN-overlay
  XYZ[ref2]:
   fNM-overlay

fsource[XYZ][fNN].acls <- dist-git[XYZ][fNN].acls
dist-git[XYZ][fNN].patches <- XYZ[fNN-overlay] - XYZ[ref1]
dist-git[XYZ][fNN].source <- XYZ[ref1].tarball
Optionally:
  dist-git[XYZ][fNN].changelog <- ~.filter(~.patches)

I have been thinking for intermediate steps with less resources 
allocation, but obviously there are consensus across the maintainers 
according the workable approach.


Kind Regards,
Alek

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ExcludeArch being ignored when building spring f20.

[Gilboa Davara]

On Wed, Nov 20, 2013 at 5:26 PM, Josh Boyer  wrote:
> On Wed, Nov 20, 2013 at 10:23 AM, Gilboa Davara  wrote:
>> Hello all,
>>
>> I'm facing a weird issue when trying to build a new version of spring.
>> First and foremost, the spring.spec has "ExcludeArch:ppc ppc64
>> %{arm}", which should exclude arm* and ppc* (both not supported by
>> upstream).
>>
>> When trying to build F20, I got the following error:
>>
>> They aren't.  The SRPM koji builds from git is failing because of:
>
> error: Bad source: /builddir/build/SOURCES/spring-95-dso.patch: No
> such file or directory
>
> SRPM creation can be done on any architecture builder.
>
>> I should point out that F21 was built just fine...
>
> You probably forgot to add the patch on the f20 branch?
>
> josh

Missing patch on my end.
Thanks for help.

- Gilboa
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enabling "-Werror=format-security" by default

[David Smith]

On 11/20/2013 10:51 AM, Dhiru Kholia wrote:
> On 11/20/13 at 09:27pm, Dhiru Kholia wrote:
>> We are working on a proposal to enable "-Werror=format-security"
>> compilation flag for all packages in Fedora.
>>
>> Currently, around 400 packages FTBFS if this flag is enabled.
> 
> A list of packages which FTBFS is available at,
> 
> http://people.fedoraproject.org/~halfie/rebuild-logs.txt

Looking at the list, I see several (~17) packages with errors of the form:


error: -Wformat-security ignored without -Wformat [-Werror=format-security]


Which is an error, but not exactly what you are trying to catch. Got any
ideas on what is going on here?

-- 
David Smith
dsm...@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora QA] #435: bugzilla sync operations are not using the correct config items

[Fedora QA]

#435: bugzilla sync operations are not using the correct config items
---+
  Reporter:  tflink|  Owner:  tflink
  Type:  defect| Status:  closed
  Priority:  critical  |  Milestone:
 Component:  Blocker bug tracker page  |Version:
Resolution:  fixed |   Keywords:
Blocked By:|   Blocking:
---+
Changes (by mkrizek):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Fixed in
 
[https://git.fedorahosted.org/cgit/blockerbugs.git/commit/?h=develop&id=39c5a3e28d22e157cd0a29efcdb328f257325489
 39c5a3e28d22e157cd0a29efcdb328f257325489]

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: F21 System Wide Change: Headless Java

[Toshio Kuratomi]

On Wed, Nov 20, 2013 at 03:04:16PM +0100, Stanislav Ochotnicky wrote:
> 
> So which one of them would "Provides: java"? I'll give you several variants:
> 
> headless provides java:
> - breaks compatibility expectations of older/3rd party RPMs
> - we suddenly switch every Java package in Fedora. No opt-out
> 
> meta package provides java (and requires both headless and x11 version):
> - doesn't change anything because you can't "yum remove java-meta" or "yum
>   remove java-x11" (due to packages having "requires: java" which is
>   satisfied by this metapackage.  And no, packages cannot have "Requires:
>   java-1.7.0-openjdk[-meta]" because there are usually multiple
>   implementations of java in Fedora. We'd be changing buildrequires every
>   few releases.
> 
> x11 version provides java:
> - That's basically what current proposal is with addition of metapackage.
>   But I fail to see the point of metapackage in this scenario
> 
The meta package should provide java.  I actually think that the meta
package providing java is closest to what the current proposal is minus the
metapackage.  Unless I'm misunderstanding the current proposal, as long as
packages Require: java but could really just need headless then there is no
change from the status quo.  It isn't until packagers modify their Requires
to java-headless that we see benefits.  So the benefit arrives at the same
time as it would with a metapackage.

Note -- If I'm reading you right and then remembering the trickiness of the
multiple-jdk's The Provides: java may be the equivalent of the
metapackage currently.  What's really missing is a Provides: java-x11 type
package.  That way packagers can mark that their package really does require
the gui bits.

> 
> Then again I might be completely missing the point of the metapackage but I've
> been trying for past day (on and off) to come up with situation where it would
> help without causing multiple other issues (or at least backward
> incompatibility) and failed... So if you can explain it, or give a better
> example how you think it should work: I'd love to be wrong.
> 
> > > I can see one advantage to this approach: it lets us tell packagers that
> > > Requires: java should no longer be used.
> 
> I don't consider that an advantage. It breaks backward compatibility for...I
> don't know. I don't mind Fedora being different. But if we diverge from
> conventions it would be great to have a *good* reason. 
> 
It doesn't break any backwards compatibility.  It gives us a deprecation
route.  ie: Requires: java works but we're telling people not to use it.

> > > Packagers should determine whether
> > > they're using APIs that require X and either Requires: java-x11 or 
> > > Requires:
> > > java-headless based on what they really need.  We can then audit the
> > > packageset at a later date to determine which packages haven't adjusted
> > > their Requirements yet
> 
> So what is stopping us from auditing the package set with current non-x11
> proposal? There will be bugzillas, it will be easy to see which packages were
> automatically converted to headless, which were supposedly fixed by their
> maintainers and then just go through them. And at any later point in time
> "repoquery --whatrequires java" will give you a list of packages that need to 
> be
> audited if they can be migrated to headless.
> 
Ease.  Querying bugzilla to find out if the package really shouldn't be
using Requires: java is a broken idea.  Firstly, it depends on mass filing
bugs against everything that Requires: java to have the maintainer evaluate
whether X11 support is needed even if it's obvious that the package does.
Second, it requires that we file bugs for every package that Requires: java
that enters the repository after the mass filing so that we have a record in
bugzilla of whether the package intends to use it or not. Thirdly, scraping
bugzilla for this information seems like a lot of work compared to using
repoquery.

So then, what's the advantage in repoquery?  If the packages that need X11
support continue to use Requires: java, there's no way to differentiate
a package which needs X11 from a package which has not been audited.  So
repoquery --whatrequires java will always return packages to you and then
you'll have to tromp through bugzilla or some other external list of
packages to decide whether you need to audit the package or if it's already
been checked.  Migrating people to java-headless and java-x11 would mean
that you know everything has been audited when "repoquery --whatrequires
java" returns aero packages.

> What *could* be done is add additional provides "java-x11" to main OpenJDK
> package and then have packagers explicitly change to either headless or x11
> version. I am not entirely sure what we'd achieve with this though (besides
> making sure someone has looked at the spec and modified it).  If we migrate 
> all
> packages to either java-x11 or java-headless those

Re: Enabling "-Werror=format-security" by default

[Adam Jackson]

On Wed, 2013-11-20 at 09:13 -0700, Jerry James wrote:
> On Wed, Nov 20, 2013 at 8:57 AM, Dhiru Kholia  wrote:
> > Currently, around 400 packages FTBFS if this flag is enabled. I am all
> > set to start filing the bugs (once given the green signal). In addition,
> > I am willing to help in patching these packages. I believe that this
> > work is important and will benefit everyone (including upstream and
> > other distributions).
> 
> It would have been nice if you had mentioned which packages failed to
> build, so maintainers could start looking at them.  I found this by
> digging around a little:
> 
> http://people.fedoraproject.org/~halfie/rebuild-logs.txt

The implementation of this flag needs some work.  The sis X driver
apparently fails the check for this code:

const char *rectxine = "\t... setting up rectangular Xinerama layout\n";
// ...
if (infochanged && !usenonrect) {
 xf86DrvMsg(pScrn1->scrnIndex, X_INFO,
"Virtual screen size does not match maximum display 
modes...\n");
 xf86DrvMsg(pScrn1->scrnIndex, X_INFO, rectxine);
}

Presumably gcc means something very precise by "string literal" here.
If I change the declaration to be const char rectxine[] it builds fine.
Which is... somewhat understandable?  I mean you _could_ assign to
rectxine-the-pointer and change what it points to, but the code does
not, so you'd hope constant-propagation would figure this out.

- ajax

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enabling "-Werror=format-security" by default

[Dhiru Kholia]

On 11/20/13 at 09:27pm, Dhiru Kholia wrote:
> We are working on a proposal to enable "-Werror=format-security"
> compilation flag for all packages in Fedora.
>
> Currently, around 400 packages FTBFS if this flag is enabled.

A list of packages which FTBFS is available at,

http://people.fedoraproject.org/~halfie/rebuild-logs.txt

The fix for these errors is quite simple. It's a matter of changing a
line like,

   printf(foo);

to read,

   printf("%s", foo);

That's it.

...

Jerry, Kevin, all,

Thanks for the feedback. I will incorporate your suggestions.

--
Dhiru
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Using git for patch management in Fedora

[Adam Jackson]

On Tue, 2013-11-19 at 10:22 +, Richard W.M. Jones wrote:

> which would expand to something like:
> 
>   git init
>   git config user.email "%{name}-ow...@fedoraproject.org"
>   git config user.name "%{name}"
>   git add .
>   git commit -a -q -m "%{version} baseline"
>   git am %{patches}

Trivial point of correctness:

git am %{patches} < /dev/null

Otherwise, in the delightful case of having no patches to apply,
non-mock-contained builds will never complete because git-am will be
waiting for a patch on stdin.

- ajax

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Source file audit - 2013-11-17

[Till Maas]

On Wed, Nov 20, 2013 at 11:50:17AM +0200, Ville Skyttä wrote:

> I think I'll make spectool tell curl not to verify SSL certs by
> default in the next release. If you want it already now for your local
> spectool, do for example this: "echo --insecure >>
> /etc/rpmdevtools/curlrc"

IMHO the default should be to check certificates, especially since
spectool is the usual tool to update source files in dist-git. Only if
there is no need to check the certificate, this should be disabled.

Regards
Till
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enabling "-Werror=format-security" by default

[Simone Caronni]

On 20 November 2013 17:25, Kevin Fenzi  wrote:

> First... I'd suggest posting the list of packages and give maintainers
> a week or two to just fix them. Then before filing anything you can run
> a quick check to see which packages are still needing fixing.
>

Yes please, sometimes the automated bug reports are a bit confusing and/or
misleading.

Thanks,
--Simone


-- 
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).

http://xkcd.com/229/
http://negativo17.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Headless Java

[Stanislav Ochotnicky]

Quoting Nicolas Mailhot (2013-11-20 16:20:34)
> 
> Le Mer 20 novembre 2013 15:04, Stanislav Ochotnicky a écrit :
> 
> > Can we actually list good reasons to have a metapackage or x11 subpackage
> > that
> > would outweight the inevitable disadvantages? If you *really* feel I
> > misunderstood these two ideas we can start an etherpad or something so we
> > can
> > ping-pong more effectively on specific issues.
> 
> What will you do when wayland arrives and you'll need to make the x11
> parts optional even for gui apps?

Wayland has and for foreseeable future will have an X11 compat layer. As far as
I am aware there is nobody working on native Wayland support in OpenJDK. So the
answer to your question is: I will do nothing because OpenJDK will need X11
libraries.

-- 
Stanislav Ochotnicky 
Software Engineer - Developer Experience

PGP: 7B087241
Red Hat Inc.   http://cz.redhat.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enabling "-Werror=format-security" by default

[Kevin Fenzi]

On Wed, 20 Nov 2013 21:27:39 +0530
Dhiru Kholia  wrote:

> Hi,
> 
> We are working on a proposal to enable "-Werror=format-security"
> compilation flag for all packages in Fedora.
> 
> Once this flag is enabled, GCC will refuse to compile code that could
> be vulnerable to a string format security flaw. For more details,
> please see https://fedorahosted.org/fesco/ticket/1185 page.
> 
> Enabling this option eliminates an entire class of security issues! To
> further understand why it is important to fix such bugs, please see
> https://fedoraproject.org/wiki/Format-Security-FAQ page.
> 
> Currently, around 400 packages FTBFS if this flag is enabled. I am all
> set to start filing the bugs (once given the green signal). In
> addition, I am willing to help in patching these packages. I believe
> that this work is important and will benefit everyone (including
> upstream and other distributions).
> 
> I am attaching a sample Bugzilla bug report - this is what the actual
> bug reports will look like.

Great. Thanks for doing this. 

First... I'd suggest posting the list of packages and give maintainers
a week or two to just fix them. Then before filing anything you can run
a quick check to see which packages are still needing fixing. 

Looking at: 

http://fedoraproject.org/wiki/Mass_bug_filing

I'd ask for a bit more in the bug report. ;) 

Might repeat the info from
https://fedoraproject.org/wiki/Format-Security-FAQ#How_do_I_fix_these_errors.3F
in the bug text (just to save people a trip to the wiki for such a
simple fixing process)

And I would add: 

Please fix this issue in rawhide with a patch (which you should submit
to upstream to merge moving forward). Please do a new build with the
fix in rawhide. Other releases do not need to be directly fixed, but
there should be no harm in pushing out this fix/patch with other needed
changes to those branches. 

And we might say: 

In the event you don't fix this bug before the next mass rebuild,
provenpackagers may step in and update your package(s) to fix this
issue. 

Otherwise looks great. ;) 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enabling "-Werror=format-security" by default

[Josh Bressers]

> 
> And the very first package I maintain that appears on that list, abe,
> is an interesting one.  The game has an internal function,
> path_sprintf(), which is static in Game.c.  All callers of that
> function are visible in the same file, and all pass constant strings
> into the function, which passes those constant strings to sprintf().
> The function's purpose is to produce a pathname for a file of interest
> to the caller in the game's installed location.  It's too bad that
> gcc's analysis cannot span function calls inside a compilation unit.
> There really is nothing wrong with this code.

You're right, some of the "bugs" aren't really bugs. It would be handy if
there was some form of taint checking in gcc, but we have to work with what
we have. We mention this in the FAQ.

https://fedoraproject.org/wiki/Format-Security-FAQ#I_don.27t_process_untrusted_string.2C_this_isn.27t_an_error.21

I would rather see us future proof all code than try to figure out each
possible use case. This is a bit of a blanket strategy, but I do think it
will have a net benefit. It's not every day you can remove an entire class
of security issues (I can count the number of times we've done this on one
hand).

Thanks.

-- 
Josh Bressers / Red Hat Product Security Team
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Enabling "-Werror=format-security" by default

[Jerry James]

On Wed, Nov 20, 2013 at 8:57 AM, Dhiru Kholia  wrote:
> Currently, around 400 packages FTBFS if this flag is enabled. I am all
> set to start filing the bugs (once given the green signal). In addition,
> I am willing to help in patching these packages. I believe that this
> work is important and will benefit everyone (including upstream and
> other distributions).

It would have been nice if you had mentioned which packages failed to
build, so maintainers could start looking at them.  I found this by
digging around a little:

http://people.fedoraproject.org/~halfie/rebuild-logs.txt

And the very first package I maintain that appears on that list, abe,
is an interesting one.  The game has an internal function,
path_sprintf(), which is static in Game.c.  All callers of that
function are visible in the same file, and all pass constant strings
into the function, which passes those constant strings to sprintf().
The function's purpose is to produce a pathname for a file of interest
to the caller in the game's installed location.  It's too bad that
gcc's analysis cannot span function calls inside a compilation unit.
There really is nothing wrong with this code.
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Enabling "-Werror=format-security" by default

[Dhiru Kholia]

Hi,

We are working on a proposal to enable "-Werror=format-security"
compilation flag for all packages in Fedora.

Once this flag is enabled, GCC will refuse to compile code that could be
vulnerable to a string format security flaw. For more details, please
see https://fedorahosted.org/fesco/ticket/1185 page.

Enabling this option eliminates an entire class of security issues! To
further understand why it is important to fix such bugs, please see
https://fedoraproject.org/wiki/Format-Security-FAQ page.

Currently, around 400 packages FTBFS if this flag is enabled. I am all
set to start filing the bugs (once given the green signal). In addition,
I am willing to help in patching these packages. I believe that this
work is important and will benefit everyone (including upstream and
other distributions).

I am attaching a sample Bugzilla bug report - this is what the actual
bug reports will look like.

--
Dhiru
Summary: grass FTBFS if "-Werror=format-security" flag is used

Description of problem:

grass fails to build if "-Werror=format-security" flag is used.

...

a2b.c:103:3: error: format not a string literal and no format arguments 
[-Werror=format-security]
a2b.c:136:3: error: format not a string literal and no format arguments 
[-Werror=format-security]
a2b.c:154:3: error: format not a string literal and no format arguments 
[-Werror=format-security]
a2b.c:172:6: error: format not a string literal and no format arguments 
[-Werror=format-security]


We are working on a proposal to enable "-Werror=format-security" for all
packages. For more details, please see 
https://fedorahosted.org/fesco/ticket/1185 page.

To understand why it is important to fix such bugs, please see
https://fedoraproject.org/wiki/Format-Security-FAQ page.

How reproducible:

Build grass-6.4.3-5.fc21.src.rpm with "-Werror=format-security" flag to 
reproduce the problem.

To make this process easier, you can use a modified "redhat-rpm-config" package
from http://people.fedoraproject.org/~halfie/artifacts/redhat-rpm-config/ URL.

$ sha256sum redhat-rpm-config-9.1.0-56.fc20.*
faad7594b2080fe76497d0ce50808c905a93dd7b41c1defdde5ca57e3833d3d2  
redhat-rpm-config-9.1.0-56.fc20.noarch.rpm
5aa9357174305c7285ffdbc92d7ffe1c07a8a95d5459b930461308f5aad75413  
redhat-rpm-config-9.1.0-56.fc20.src.rpm
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Source file audit - 2013-11-17

[Ville Skyttä]

On Wed, Nov 20, 2013 at 11:50 AM, Ville Skyttä  wrote:
>
> I think I'll make spectool tell curl not to verify SSL certs by default in 
> the next release.

https://git.fedorahosted.org/cgit/rpmdevtools.git/commit/?id=363b0d5bbd92e2cac2a9ba632af54e303ffc491d
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ExcludeArch being ignored when building spring f20.

[Dan Horák]

On Wed, 20 Nov 2013 17:23:33 +0200
Gilboa Davara  wrote:

> Hello all,
> 
> I'm facing a weird issue when trying to build a new version of spring.
> First and foremost, the spring.spec has "ExcludeArch:ppc ppc64
> %{arm}", which should exclude arm* and ppc* (both not supported by
> upstream).

also a question is whether you should rather do ExclusiveArch: %[ix86}
x86_64 because there are other arches in Fedora like s390 or aarch64
which are very likely also unsupported


Dan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Source file audit - 2013-11-17

[Alexey I. Froloff]

On Mon, Nov 18, 2013 at 08:54:01AM -0700, Kevin Fenzi wrote:
> - This run was done on a Fedora 20 instance, so hopefully many of the
>   false positives due to old tools from the last run are gone. 
Those are still false positives:

> raorn:BADSOURCE:wmMatrix-0.2-g97216606.tar.gz:wmMatrix
> raorn:BADSOURCE:wmmon-1.0b2-g575778a6.tar.gz:wmmon
> raorn:BADSOURCE:wmpager-1.2-g88ece7e5.tar.gz:wmpager

-- 
Regards,--
Sir Raorn.   --- http://thousandsofhate.blogspot.com/


signature.asc
Description: Digital signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-Sub-Install] Update BRs

[Jitka Plesnikova]

commit b5e3e3af1ba9f35f5dc363393265a02bddc0fecf
Author: Jitka Plesnikova 
Date:   Wed Nov 20 16:41:02 2013 +0100

Update BRs

 perl-Sub-Install.spec |   25 +++--
 1 files changed, 15 insertions(+), 10 deletions(-)
---
diff --git a/perl-Sub-Install.spec b/perl-Sub-Install.spec
index 66e2caf..e87cd8e 100644
--- a/perl-Sub-Install.spec
+++ b/perl-Sub-Install.spec
@@ -1,6 +1,6 @@
 Name:   perl-Sub-Install
 Version:0.927
-Release:1%{?dist}
+Release:2%{?dist}
 Summary:Install subroutines into packages easily
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -9,24 +9,26 @@ Source0:
http://www.cpan.org/authors/id/R/RJ/RJBS/Sub-Install-%{version}.
 BuildRoot:  %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
 BuildArch:  noarch
 # = Module Build 
-BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl
+BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.30
+BuildRequires:  perl(strict)
+BuildRequires:  perl(warnings)
 # = Run-time 
+BuildRequires:  perl(B)
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(Scalar::Util)
 # = Test Suite ==
-BuildRequires:  perl(Test::More)
+BuildRequires:  perl(File::Spec)
+BuildRequires:  perl(IO::Handle)
+BuildRequires:  perl(IPC::Open3)
+BuildRequires:  perl(Test::More) >= 0.94
 %if !%{defined perl_bootstrap}
 # Test::Output -> Sub::Exporter -> Sub::Install
 BuildRequires:  perl(Test::Output)
-# Test::Perl::Critic -> Perl::Critic -> Exception::Class ->
-#   Test::EOL -> Pod::Coverage::TrustPod -> Pod::Eventual ->
-#   Mixin::Linewise -> Sub::Exporter -> Sub::Install
-BuildRequires:  perl(Test::Perl::Critic)
 %endif
-BuildRequires:  perl(Test::Pod)
-BuildRequires:  perl(Test::Pod::Coverage)
 # = Run-time 
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
+Requires:   perl(B)
 
 %description
 This module makes it easy to install subroutines into packages without the
@@ -47,7 +49,7 @@ find %{buildroot} -type f -name .packlist -exec rm -f {} \;
 %{_fixperms} %{buildroot}
 
 %check
-make test %{!?perl_bootstrap:PERL_TEST_CRITIC=1}
+make test
 
 %clean
 rm -rf %{buildroot}
@@ -58,6 +60,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/Sub::Install.3pm*
 
 %changelog
+* Wed Nov 20 2013 Jitka Plesnikova  - 0.927-2
+- Update BRs
+
 * Wed Nov 13 2013 Robin Lee  - 0.927-1
 - Update to 0.927
 
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: [Fedora QA] #436: SSH access to systems in Beaker lab

[Fedora QA]

#436: SSH access to systems in Beaker lab
---+
  Reporter:  atodorov  |  Owner:  tflink
  Type:  defect| Status:  new
  Priority:  major |  Milestone:
 Component:  Blocker bug tracker page  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+

Comment (by tflink):

 yeah, it's not ideal but I did tell him to file bugs this way :)

 Eventually, I want to put this all in phabricator. I'm just hesitating on
 asking people to use it until we have FAS integration.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
___
qa-devel mailing list
qa-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/qa-devel

Re: ExcludeArch being ignored when building spring f20.

[Christopher Meng]

Adding files must be accomplished by git add, or fedpkg won't include it
due to a bug in GitPython.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: ExcludeArch being ignored when building spring f20.

[Josh Boyer]

On Wed, Nov 20, 2013 at 10:23 AM, Gilboa Davara  wrote:
> Hello all,
>
> I'm facing a weird issue when trying to build a new version of spring.
> First and foremost, the spring.spec has "ExcludeArch:ppc ppc64
> %{arm}", which should exclude arm* and ppc* (both not supported by
> upstream).
>
> When trying to build F20, I got the following error:
>
> Building spring-95.0-1.fc20 for f20-candidate
> Created task: 6205737
> Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=6205737
> Watching tasks (this may be safely interrupted)...
> 6205737 build (f20-candidate,
> /spring:bdcff90c696261332269632c667ad2b3505b749c): open
> (buildppc-01.phx2.fedoraproject.org)
>   6205738 buildSRPMFromSCM
> (/spring:bdcff90c696261332269632c667ad2b3505b749c): open
> (arm02-builder10.arm.fedoraproject.org)
>   6205738 buildSRPMFromSCM
> (/spring:bdcff90c696261332269632c667ad2b3505b749c): open
> (arm02-builder10.arm.fedoraproject.org) -> FAILED: BuildError: error
> building srpm, mock exited with status 1; see build.log for more
> information
>   0 free  1 open  0 done  1 failed
> 6205737 build (f20-candidate,
> /spring:bdcff90c696261332269632c667ad2b3505b749c): open
> (buildppc-01.phx2.fedoraproject.org) -> FAILED: BuildError: error
> building srpm, mock exited with status 1; see build.log for more
> information
>   0 free  0 open  0 done  2 failed
>
> 6205737 build (f20-candidate,
> /spring:bdcff90c696261332269632c667ad2b3505b749c) failed
>
> Why is arm and ppc being built?

They aren't.  The SRPM koji builds from git is failing because of:

error: Bad source: /builddir/build/SOURCES/spring-95-dso.patch: No
such file or directory

SRPM creation can be done on any architecture builder.

> I should point out that F21 was built just fine...

You probably forgot to add the patch on the f20 branch?

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Schedule for Wednesday's FESCo Meeting (2013-11-20)

[Josh Boyer]

On Tue, Nov 19, 2013 at 3:08 PM, Stephen Gallagher  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/19/2013 02:47 PM, Josh Boyer wrote:
>>
>> On Nov 19, 2013 12:55 PM, "Stephen Gallagher" > > wrote:
>>>
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>>
>>> Following is the list of topics that will be discussed in the
>>> FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on
>>> irc.freenode.net
>> .
>>>
>>> To convert UTC to your local time, take a look at
>>> http://fedoraproject.org/wiki/UTCHowto
>>>
>>> or run: date -d '-MM-DD HH:MM UTC'
>>>
>>>
>>> Links to all tickets below can be found at:
>>> https://fedorahosted.org/fesco/report/9
>>>
>>> = Followups =
>>>
>>> #topic #1193 reboots for all updates -- are we ready for this?
>>> .fesco 1193 https://fedorahosted.org/fesco/ticket/1193
>>>
>>> #topic #1185 Enable "-Werror=format-security" by default .fesco
>>> 1185 https://fedorahosted.org/fesco/ticket/1185
>>>
>>> #topic #1198 Possible changes to Fedora EOL bug procedure .fesco
>>> 1198 https://fedorahosted.org/fesco/ticket/1198
>>>
>>> #topic #1140 F20 Self Contained Changes - week 2013-07-10 -
>>> 2013-07-17 .fesco 1140
>>> https://fedorahosted.org/fesco/ticket/1140
>>>
>>> = New business =
>>
>> FESCo asked that I file a separate ticket for the third party repo
>> question.  Is it not going to be discussed?
>>
>
> Sorry, wasn't tagged with the "meeting" keyword. Consider it added.
>
> #topic #1201 Enabling third party repositories
> .fesco 1201
> https://fedorahosted.org/fesco/ticket/1201

There's also the Workstation WG governance charter ticket:

https://fedorahosted.org/fesco/ticket/1205

The charters were due Friday, which is an odd day in terms of FESCo
schedule, and we squeaked in just in time.

josh
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

ExcludeArch being ignored when building spring f20.

[Gilboa Davara]

Hello all,

I'm facing a weird issue when trying to build a new version of spring.
First and foremost, the spring.spec has "ExcludeArch:ppc ppc64
%{arm}", which should exclude arm* and ppc* (both not supported by
upstream).

When trying to build F20, I got the following error:

Building spring-95.0-1.fc20 for f20-candidate
Created task: 6205737
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=6205737
Watching tasks (this may be safely interrupted)...
6205737 build (f20-candidate,
/spring:bdcff90c696261332269632c667ad2b3505b749c): open
(buildppc-01.phx2.fedoraproject.org)
  6205738 buildSRPMFromSCM
(/spring:bdcff90c696261332269632c667ad2b3505b749c): open
(arm02-builder10.arm.fedoraproject.org)
  6205738 buildSRPMFromSCM
(/spring:bdcff90c696261332269632c667ad2b3505b749c): open
(arm02-builder10.arm.fedoraproject.org) -> FAILED: BuildError: error
building srpm, mock exited with status 1; see build.log for more
information
  0 free  1 open  0 done  1 failed
6205737 build (f20-candidate,
/spring:bdcff90c696261332269632c667ad2b3505b749c): open
(buildppc-01.phx2.fedoraproject.org) -> FAILED: BuildError: error
building srpm, mock exited with status 1; see build.log for more
information
  0 free  0 open  0 done  2 failed

6205737 build (f20-candidate,
/spring:bdcff90c696261332269632c667ad2b3505b749c) failed

Why is arm and ppc being built?
I should point out that F21 was built just fine...

Thanks,
- Gilboa
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Headless Java

[Nicolas Mailhot]

Le Mer 20 novembre 2013 15:04, Stanislav Ochotnicky a écrit :

> Can we actually list good reasons to have a metapackage or x11 subpackage
> that
> would outweight the inevitable disadvantages? If you *really* feel I
> misunderstood these two ideas we can start an etherpad or something so we
> can
> ping-pong more effectively on specific issues.

What will you do when wayland arrives and you'll need to make the x11
parts optional even for gui apps? That was always the core problem of
SUN's "stuff everything in the default install" approach: it avoids
looking for optional parts, but the base install slowly accrues layers of
not-so-useful and perhaps-deprecated bits.

Regards,

-- 
Nicolas Mailhot

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F21 System Wide Change: Headless Java

[Stanislav Ochotnicky]

Quoting Reindl Harald (2013-11-19 23:38:21)
> 
> 
> Am 19.11.2013 20:29, schrieb Toshio Kuratomi:
> > On Tue, Nov 19, 2013 at 01:29:58PM -0500, Stephen Gallagher wrote:
> >> On 11/19/2013 11:23 AM, Reindl Harald wrote:
> >>> what about having a "java-1.7.0-openjdk" meta-package obsoleting
> >>> the existing one and pulling *both* but decide if Fedora packages
> >>> if the headless is enough for dependencies and so packagers of
> >>> sevrer software can require this?
> >>>
> >>> this way you would have the least surprise for someone who does not
> >>> care about the difference and expects the full one by install
> >>> "java-1.7.0-openjdk" but make it really easy to uninstall any
> >>> graphical dependencies on servers
> >>>
> >> I agree with Reindl here, if I understand him correctly. It would
> >> certainly break upgrades in an unexpected way if an upgrade from
> >> "java-1.7.0-openjdk" suddenly stopped carrying the graphical components.
> > 
> > Note -- I think that the way the feature has things constructed would
> > achieve something similar.  The java package is essentially java-x11.  It
> > would Require: java-headless.
> > 
> > So yum install java will get you the java w/X11 support.
> > 
> >> I think it would be wise to do the same for Java. Create
> >> 'java-openjdk-1.7.0-headless' and 'java-openjdk-1.7.0--x11' and then
> >> have the 'java-openjdk-1.7.0' metapackage install both of them.
> >>

So which one of them would "Provides: java"? I'll give you several variants:

headless provides java:
- breaks compatibility expectations of older/3rd party RPMs
- we suddenly switch every Java package in Fedora. No opt-out

meta package provides java (and requires both headless and x11 version):
- doesn't change anything because you can't "yum remove java-meta" or "yum
  remove java-x11" (due to packages having "requires: java" which is
  satisfied by this metapackage.  And no, packages cannot have "Requires:
  java-1.7.0-openjdk[-meta]" because there are usually multiple
  implementations of java in Fedora. We'd be changing buildrequires every
  few releases.

x11 version provides java:
- That's basically what current proposal is with addition of metapackage.
  But I fail to see the point of metapackage in this scenario


Then again I might be completely missing the point of the metapackage but I've
been trying for past day (on and off) to come up with situation where it would
help without causing multiple other issues (or at least backward
incompatibility) and failed... So if you can explain it, or give a better
example how you think it should work: I'd love to be wrong.

> > I can see one advantage to this approach: it lets us tell packagers that
> > Requires: java should no longer be used.

I don't consider that an advantage. It breaks backward compatibility for...I
don't know. I don't mind Fedora being different. But if we diverge from
conventions it would be great to have a *good* reason. 

> > Packagers should determine whether
> > they're using APIs that require X and either Requires: java-x11 or Requires:
> > java-headless based on what they really need.  We can then audit the
> > packageset at a later date to determine which packages haven't adjusted
> > their Requirements yet

So what is stopping us from auditing the package set with current non-x11
proposal? There will be bugzillas, it will be easy to see which packages were
automatically converted to headless, which were supposedly fixed by their
maintainers and then just go through them. And at any later point in time
"repoquery --whatrequires java" will give you a list of packages that need to be
audited if they can be migrated to headless.

> agreed, but with the meta-package nobody is forced to change anything
> while any maintainer at any time can say "hey, we do not need the
> graphical components and so we relax now the dependencies"
>
> so anybody can point at any time to whatever package and ask for
> relax the deps to java-headless and at no point in time any change
> is forced since the expierience shows changes can't be forced inside
> Fedora - look how long it took to get native systemd-units and there
> are still packages with sysv-init-scripts

As stated above, metapackage introduces more issues and doesn't solve any.
You can't migrate your package to headless in isolation. You have to migrate
*all* dependencies for it to have any noticeable effect.

What *could* be done is add additional provides "java-x11" to main OpenJDK
package and then have packagers explicitly change to either headless or x11
version. I am not entirely sure what we'd achieve with this though (besides
making sure someone has looked at the spec and modified it). If we migrate all
packages to either java-x11 or java-headless those RPMs lose compatibility with
older Fedoras, RHELs etc. Inevitably %if macros will be creeping in and...what
for? So that we can say: "Yes, we have looked at the spec file". 

Last by not least t

Re: Source file audit - 2013-11-17

[Germán A. Racca]

On 11/20/2013 07:50 AM, Ville Skyttä wrote:

On Wed, Nov 20, 2013 at 10:58 AM, "Germán A. Racca"
 wrote:


What should I do with this [*]? Report upstream?
I can successfully download the tarball from Firefox, but using spectool
gives that error.
[*]
curl: (60) Peer's Certificate issuer is not recognized.
More details here: http://curl.haxx.se/docs/sslcerts.html


I think I'll make spectool tell curl not to verify SSL certs by
default in the next release. If you want it already now for your local
spectool, do for example this: "echo --insecure >>
/etc/rpmdevtools/curlrc"



It works fine creating that file. If the only solution is to not verify 
SSL certs by default, then please do it.


Thanks,
--
Germán A. Racca
Fedora Package Maintainer
https://fedoraproject.org/wiki/User:Skytux
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

F-20 Branched report: 20131120 changes

[Fedora Branched Report]

Compose started at Wed Nov 20 09:15:03 UTC 2013

Broken deps for armhfp
--
[avro]
avro-mapred-1.7.5-1.fc20.noarch requires hadoop-mapreduce
avro-mapred-1.7.5-1.fc20.noarch requires hadoop-client
[blueman]
blueman-1.23-7.fc20.armv7hl requires obex-data-server >= 0:0.4.3
blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp
[cloud-init]
cloud-init-0.7.2-7.fc20.noarch requires dmidecode
[cobbler]
cobbler-2.4.0-2.fc20.noarch requires syslinux
[condor-wallaby]
condor-wallaby-client-5.0.3-5.fc20.noarch requires python-qpid-qmf >= 
0:0.9.1073306
[fence-agents]
fence-agents-common-4.0.4-3.fc20.armv7hl requires pexpect
[fts]
fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14
[glpi]
glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Version
glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Stdlib
glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-ServiceManager
glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Loader
glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-I18n
glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Cache-apc
glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Cache
[gnome-do-plugins]
gnome-do-plugins-thunderbird-0.8.4-14.fc20.armv7hl requires thunderbird
[gofer]
ruby-gofer-0.75-4.fc20.noarch requires rubygem(qpid) >= 0:0.16.0
[gtkd]
gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 
0:2.0.0-29.20120815git9ae9181.fc18
[ipython]
python-ipython-console-0.13.2-2.fc20.noarch requires pexpect
python3-ipython-console-0.13.2-2.fc20.noarch requires python3-pexpect
[kawa]
1:kawa-1.11-5.fc19.armv7hl requires servlet25
[koji]
koji-vm-1.8.0-2.fc20.noarch requires python-virtinst
[kyua-cli]
kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0
kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0
[mozilla-firetray]
mozilla-firetray-thunderbird-0.3.6-0.5.143svn.fc18.1.armv7hl requires 
thunderbird >= 0:11
[msp430-libc]
msp430-libc-20120224-2.fc19.noarch requires msp430-gcc >= 0:4.6.3
[nifti2dicom]
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10
nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10
[nocpulse-common]
nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI)
[openbox]
gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel
gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel
[openlmi-providers]
openlmi-0.4.0-1.fc20.noarch requires openlmi-power
[openpts]
openpts-0.2.6-7.fc20.armv7hl requires tboot
[perl-Language-Expr]
perl-Language-Expr-0.19-4.fc19.noarch requires 
perl(:MODULE_COMPAT_5.16.2)
[pure]
pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20
[python-requests-oauthlib]
python-requests-oauthlib-0.4.0-2.fc20.noarch requires python-oauthlib
[python-tag]
python-tag-2013.1-1.fc20.armv7hl requires libboost_python.so.1.53.0
[qpid-cpp]
qpid-cpp-server-ha-0.24-6.fc20.armv7hl requires qpid-qmf(armv7hl-32)
qpid-tools-0.24-6.fc20.noarch requires python-qpid-qmf
[rootplot]
rootplot-2.2.1-7.fc19.noarch requires root-python
[ruby-spqr]
ruby-spqr-0.3.6-7.fc20.noarch requires ruby-qpid-qmf
[rubygem-audited-activerecord]
rubygem-audited-activerecord-3.0.0-3.fc19.noarch requires 
rubygem(activerecord) < 0:4
[scilab]
scilab-doc-5.4.1-4.fc20.noarch requires scilab = 0:5.4.1-4.fc20
scilab-tests-5.4.1-4.fc20.noarch requires scilab = 0:5.4.1-4.fc20
[sigul]
sigul-0.100-3.fc20.noarch requires pexpect
[spacewalk-admin]
spacewalk-admin-2.0.1-2.fc20.noarch requir

Re: F21 System Wide Change: Headless Java

[Nicolas Mailhot]

Le Mar 19 novembre 2013 09:35, Stanislav Ochotnicky a écrit :

> You can use following Oracle article as a starting point[1]. But maybe
> OpenJDK
> maintainers can provide better alternative. Generally though there are
> *very*
> few packages in Fedora that would require full java.
>
>
> [1] http://www.oracle.com/technetwork/articles/javase/headless-136834.html

May I point out that when jpackage tried to streamline Java packaging we
unilaterally decided java would mean the JRE (not the full jdk as was
commonly used at the time) and various gui bits suchs as fonts were moved
to separate subpackages

So having the main java package mean 'something minimal sufficient for
most uses, add other subpackages if you need to' is nothing new.

Regards,

-- 
Nicolas Mailhot

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Packaging changes for libev in Rawhide

[Michael Schwendt]

On Wed, 20 Nov 2013 11:24:34 +0800, Mathieu Bridon wrote:

> > The current packaging approach is circumventing the packaging policies:
> > https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
> > 
> > perl-EV does not use the system libev. No real "unbundling" has been
> > achieved by replacing the bundled source with another copy at build-time.
> > A bug-fix (or security-fix) of libev would not affect perl-EV without
> > rebuilding perl-EV. Even rebuilding perl-EV isn't safe. There's no strict
> > dependency, but only:
> > 
> >   BuildRequires:  libev-source >= %{version}
> > 
> > As a result, it is not ensured that a rebuild picks up the latest patched
> > libev-source. Even a buildroot override would be needed.
> 
> I know all that. :)

That makes it more difficult to answer.

In the original review request, it was mentioned to "request an exemption
from FESCo": https://bugzilla.redhat.com/448613

In the ticket, you mention:
 |
 | [...] the bundled ones have always been identical to the system
 | ones we use to build our libev package), but in that the built
 | binaries are ABI-incompatible.

The ticket has been closed over a year later to restart with another review:
https://bugzilla.redhat.com/678221

In that ticket, the missing unbundling has not been commented on by the
reviewer. There is no explicit acknowledgement either. You explain:
 |
 | There's a bundled copy of libev in the source RPM.
 |
 | At build-time, I remove this folder and use instead the sources coming
 | from the Fedora libev-source package, to avoid building against the
 | bundled copy (this is what is done by other packages such as tigervnc
 | that uses the sources from Xorg).

Effectively, and repeating that cannot be avoided, you restore the bundled
sources, an no "unbundling" is done. More precisely, you replace the
bundled sources with a copy that may be different (especially for the case
that "libev" is at a different version than what is bundled with "perl-EV").

Nobody care foresee how long the sources will be "identical". Currently,
upstream perl-EV in CVS does not include a bundled libev, but refers to the
separate libev project in CVS. Anyone, who checks out perl-EV from CVS
will need to check out libev, since the bundling is only done for the
tarball release - so far.

> Unbundling was a pre-requisite of the review request, though, and the
> reviewer found the current solution more acceptable than keeping the
> bundled libev in perl-EV.
> 
> I'm really just trying to fix all this mess here, so what do you think
> would be the better solution?

To follow:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

In the case of the FPC not granting a bundling exception, perhaps they
would permit building libev and perl-EV from the same src.rpm. The rationale
for that would be how upstream handles the sources in CVS.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Using git for patch management in Fedora

[Dridi Boukelmoune]

Hi,

For github-hosted upstreams, you can suffix some URLs with '.diff' or
'.patch'. I have used it for vcsh [1] (which btw is a tool I'd
recommend to anyone who keeps dotfiles in sync on several machines). I
did that on a pull request, but you can also do that on a commit (for
cherry-picking) [2] and github even allows you to use a shortened
sha-1 [3].

Of course this doesn't prevent you from putting the patch files in the
package's repository, which seems to be the main issue. But one could
write a script to fetch such patches at %prep time.

Dridi

[1] http://pkgs.fedoraproject.org/cgit/vcsh.git/tree/vcsh.spec
[2] 
https://github.com/RichiH/vcsh/commit/c0d0f80513f26e7b6a485bbd6239191a3fe4be59.diff
[3] https://github.com/RichiH/vcsh/commit/c0d0f80.diff

On Wed, Nov 20, 2013 at 10:19 AM, Richard W.M. Jones  wrote:
> On Tue, Nov 19, 2013 at 03:36:54PM -0800, Toshio Kuratomi wrote:
>> One note though, I think that in the past one of the discussion points we've
>> foundered on is whether we want to be mirroring upstream's git repo or
>> (approximately) upstream's releases.  I think that's probably where we'd
>> need to start discussion.
>
> From the point of view of patch management, I have a strong view here:
>
> We should be mirroring upstream's git, if they have one.
>
> The reason is that it makes it trivial to cherry pick upstream patches
> on top of the Fedora branch.
>
> So I'd arrange it by having a straight mirror of upstream, then have
> our own 'fNN-branch' branches which contain the upstream releases
> (ideally from upstream tags if they are using git sensibly) + our
> cherry picked patches.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
> Fedora Windows cross-compiler. Compile Windows programs, test, and
> build Windows installers. Over 100 libraries supported.
> http://fedoraproject.org/wiki/MinGW
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Using git for patch management in Fedora

[Daniel P. Berrange]

On Wed, Nov 20, 2013 at 09:58:00AM +0100, Karel Zak wrote:
> On Tue, Nov 19, 2013 at 02:20:30PM +, Daniel P. Berrange wrote:
> > On Tue, Nov 19, 2013 at 01:29:06PM +, Richard W.M. Jones wrote:
> > > On Tue, Nov 19, 2013 at 01:39:50PM +0100, Karel Zak wrote:
> > > > We have to learn fedpkg to do all the magic ;-) Something like
> > > > 
> > > > add remote git tree with exploded tree:
> > > > 
> > > >   fedpkg exploded-tree add ssh://git.fedorahosted.org/git/foo.git
> > > 
> > > This is all great, but the problem is that co-maintainers and
> > > provenpackagers need to be (automatically if possible) added to the
> > > fedorahosted tree.  Otherwise there's a big extra step for them if
> > > they want to follow the package owner's preferred patching system.
> 
> BTW, why we cannot use pkgs.fedoraproject.org for exploded tree too?
> Just another set of repositories, maybe with a different HTTP alias,
> e.g. extree.fedoraproject.org, or so...

That's entirely possibile - the key points to me are just that the
repos are separate, and access control is applied uniformly across
both. Beyond that I don't care where they are actually hosted.

> 
> > Ideally the GIT SCM request added to bugzilla when reviews are
> > approved would have a "Upstream GIT URL" option and would setup
> > a clone of this, and create branches for the fedora releases,
> > and apply the same permissioning model from dist-git branches
> > of the same names.
> 
> All such information belong to spec file :-)
> 
>   Fedora-SCM:
>   Upstream-SCM:
>   Exploded-tree-SCM:
> 
> for example upstream SCM URL is already missing in our spec files,
> it's more important information than URL to tarball.

I suggested the GIT SCM request, because that's where the tools
already look for this kind of info, so it'd be a simpler addition
to the GIT creation process.

Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Using git for patch management in Fedora

[Daniel P. Berrange]

On Tue, Nov 19, 2013 at 03:36:54PM -0800, Toshio Kuratomi wrote:
> On Tue, Nov 19, 2013 at 05:32:01PM +, Daniel P. Berrange wrote:
> > On Tue, Nov 19, 2013 at 07:27:20PM +0200, Alek Paunov wrote:
> > > On 19.11.2013 16:20, Daniel P. Berrange wrote:
> > > >On Tue, Nov 19, 2013 at 01:29:06PM +, Richard W.M. Jones wrote:
> > > >>On Tue, Nov 19, 2013 at 01:39:50PM +0100, Karel Zak wrote:
> > > >>>We have to learn fedpkg to do all the magic ;-) Something like
> > > >>>
> > > >>>add remote git tree with exploded tree:
> > > >>>
> > > >>>   fedpkg exploded-tree add ssh://git.fedorahosted.org/git/foo.git
> > > >>
> > > >>This is all great, but the problem is that co-maintainers and
> > > >>provenpackagers need to be (automatically if possible) added to the
> > > >>fedorahosted tree.  Otherwise there's a big extra step for them if
> > > >>they want to follow the package owner's preferred patching system.
> > > >
> > > >Ideally the GIT SCM request added to bugzilla when reviews are
> > > >approved would have a "Upstream GIT URL" option and would setup
> > > >a clone of this, and create branches for the fedora releases,
> > > >and apply the same permissioning model from dist-git branches
> > > >of the same names.
> > > >
> > > 
> > > What about intermediate step: optional "fNN-upstream" branch in
> > > addition to fNN, containing relevant upstream revision as git
> > > submodule (preferably referencing fedorahosted mirror, but initially
> > > also allowing "external" clones)?
> > 
> > I think it would be better to keep the upstream repo separate for
> > sake of size. People who just want to checkout the latest RPM
> > branches don't want to have to pull down 100's of MB, potentially
> > GB, worth of GIT repo, when current Fedora GIT repos are a mere
> > few MB. Only maintainers actively updating patches need that
> > burden.
> > 
> It probably makes sense to have a "lookaside git" that's similar to the
> "lookaside cache".
> 
> One note though, I think that in the past one of the discussion points we've
> foundered on is whether we want to be mirroring upstream's git repo or
> (approximately) upstream's releases.  I think that's probably where we'd
> need to start discussion.

For it to be useful to me we'd need to be mirroring the upstream git
repo continuously, not just at releases. I will frequently cherry-pick
patches directly from GIT master into the Fedora maint branches that I
maintain.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Source file audit - 2013-11-17

[Ville Skyttä]

On Wed, Nov 20, 2013 at 10:58 AM, "Germán A. Racca"
 wrote:
>
> What should I do with this [*]? Report upstream?
> I can successfully download the tarball from Firefox, but using spectool
> gives that error.
> [*]
> curl: (60) Peer's Certificate issuer is not recognized.
> More details here: http://curl.haxx.se/docs/sslcerts.html

I think I'll make spectool tell curl not to verify SSL certs by
default in the next release. If you want it already now for your local
spectool, do for example this: "echo --insecure >>
/etc/rpmdevtools/curlrc"
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Using git for patch management in Fedora

[Richard W.M. Jones]

On Tue, Nov 19, 2013 at 03:36:54PM -0800, Toshio Kuratomi wrote:
> One note though, I think that in the past one of the discussion points we've
> foundered on is whether we want to be mirroring upstream's git repo or
> (approximately) upstream's releases.  I think that's probably where we'd
> need to start discussion.

From the point of view of patch management, I have a strong view here:

We should be mirroring upstream's git, if they have one.

The reason is that it makes it trivial to cherry pick upstream patches
on top of the Fedora branch.

So I'd arrange it by having a straight mirror of upstream, then have
our own 'fNN-branch' branches which contain the upstream releases
(ideally from upstream tags if they are using git sensibly) + our
cherry picked patches.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Source file audit - 2013-11-17

[Tom Hughes]

On 20/11/13 08:58, "Germán A. Racca" wrote:


What should I do with this [*]? Report upstream?
I can successfully download the tarball from Firefox, but using spectool
gives that error.


You must have added the CAcert root certificate to Firefox then, because 
that URL redirects to https://www.pekwm.org/ and that is using a CAcert 
certificate, which nothing will trust by default.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Using git for patch management in Fedora

[Peter Lemenkov]

2013/11/20 Karel Zak :

> All such information belong to spec file :-)
>
>   Fedora-SCM:
>   Upstream-SCM:
>   Exploded-tree-SCM:
>
> for example upstream SCM URL is already missing in our spec files,
> it's more important information than URL to tarball.

Love this idea but there is a problem - RPM (at least older versions)
doesn't like unknown fields. It throws error and dies.
-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Source file audit - 2013-11-17

[Germán A. Racca]

On 11/18/2013 01:54 PM, Kevin Fenzi wrote:

Here's attached another run of my sources/patches url checker.
Please fix any packages you are responsible for in rawhide, and other
branches as other changes permit.

- This run was done on a Fedora 20 instance, so hopefully many of the
   false positives due to old tools from the last run are gone.

- I didn't explicitly mention it last time, but you can find the output
   of the script for your package at:

http://www.scrye.com/~kevin/fedora/sourcecheck-20131117/$packagename-dl.txt

This should help determine what the script saw that caused it to list
your package.

- The script simply checks has a checkout of your package and runs
   'spectool -g packagename.spec' on it. Then it checks the md5sum of
   anything in sources file against those downloaded sources.

- There are 1870 lines in this run. Down from 3067 last run.
(Likely due to reducing false positives due to old spectool)

700 sourcecheck-20070826.txt
620 sourcecheck-20070917.txt
561 sourcecheck-20071017.txt
775 sourcecheck-20080206.txt
685 sourcecheck-20080214.txt
674 sourcecheck-20080301.txt
666 sourcecheck-20080401.txt
660 sourcecheck-20080501.txt
642 sourcecheck-20080603.txt
649 sourcecheck-20080705.txt
662 sourcecheck-20080801.txt
912 sourcecheck-20081114.txt
884 sourcecheck-20090215.txt
   1060 sourcecheck-20090810.txt
932 sourcecheck-20091101.txt
932 sourcecheck-20091104.txt
   1612 sourcecheck-20100105.txt
   1391 sourcecheck-20100106.txt
   1007 sourcecheck-20100531.txt
   3067 sourcecheck-20130930.txt
   1870 sourcecheck-20131117.txt

You can find the results file at:

http://www.scrye.com/~kevin/fedora/sourcecheck/sourcecheck-20131117.txt

And also attached to this mail.

Lines in the output are of three forms:

- BADURL:base-file-name:$PACKAGENAME

This means that the URI provided in the Source(s) line didn't result in
a download of the source. This could be any of: URL changed, version
changed and URL wasn't updated, Site is down, Site is gone, etc.
Also there are a number of packages with incorrect sourceforge links.
(BTW, there are still some packages with ftp://people.redhat.com/
URLs).

- BADSOURCE:$SOURCENAME:$PACKAGENAME

This means that the source was downloaded ok from the upstream site,
but doesn't match the md5sum given in the sources file.
This could be due to needing to strip out content that fedora cannot
ship (but in that case you shouldn't have the full URI in the Source
line). Or upstream following poor release practices and updating
without changing their release.

- BAD_CVS_SOURCE:$SOURCENAME:$PACKAGENAME

This means that the file was downloaded from the URI given, and the
md5sum did not match the file thats present in git (not the lookaside).
This might be due to timestamps, or any of the above reasons.

kevin
--


Hi Kevin,

What should I do with this [*]? Report upstream?
I can successfully download the tarball from Firefox, but using spectool 
gives that error.


Thanks,
Germán.

[*]
Getting http://www.pekwm.org/projects/pekwm/files/pekwm-0.1.17.tar.bz2 
to ./pekwm-0.1.17.tar.bz2
  % Total% Received % Xferd  Average Speed   TimeTime Time 
 Current
 Dload  Upload   Total   SpentLeft 
 Speed


  0 00 00 0  0  0 --:--:-- --:--:-- 
--:--:-- 0
100   160  100   1600 0196  0 --:--:-- --:--:-- --:--:-- 
  196
100   160  100   1600 0196  0 --:--:-- --:--:-- --:--:-- 
  196

curl: (60) Peer's Certificate issuer is not recognized.
More details here: http://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

--
Germán A. Racca
Fedora Package Maintainer
https://fedoraproject.org/wiki/User:Skytux
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Using git for patch management in Fedora

[Karel Zak]

On Tue, Nov 19, 2013 at 02:20:30PM +, Daniel P. Berrange wrote:
> On Tue, Nov 19, 2013 at 01:29:06PM +, Richard W.M. Jones wrote:
> > On Tue, Nov 19, 2013 at 01:39:50PM +0100, Karel Zak wrote:
> > > We have to learn fedpkg to do all the magic ;-) Something like
> > > 
> > > add remote git tree with exploded tree:
> > > 
> > >   fedpkg exploded-tree add ssh://git.fedorahosted.org/git/foo.git
> > 
> > This is all great, but the problem is that co-maintainers and
> > provenpackagers need to be (automatically if possible) added to the
> > fedorahosted tree.  Otherwise there's a big extra step for them if
> > they want to follow the package owner's preferred patching system.

BTW, why we cannot use pkgs.fedoraproject.org for exploded tree too?
Just another set of repositories, maybe with a different HTTP alias,
e.g. extree.fedoraproject.org, or so...

> Ideally the GIT SCM request added to bugzilla when reviews are
> approved would have a "Upstream GIT URL" option and would setup
> a clone of this, and create branches for the fedora releases,
> and apply the same permissioning model from dist-git branches
> of the same names.

All such information belong to spec file :-)

  Fedora-SCM:
  Upstream-SCM:
  Exploded-tree-SCM:

for example upstream SCM URL is already missing in our spec files,
it's more important information than URL to tarball.

Karel

-- 
 Karel Zak  
 http://karelzak.blogspot.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct