Re: [Fedora-packaging] critical path security update policy
by Jerry Bratton
>> I'm concerned about how long it takes security updates to make it to users
>> under Fedora's current policies (which generally allow such updates the
>> possibility of sitting in testing for 14 days, or even longer).
>>
>> Just one example is the Firefox 37.0.1 update for Fedora 20:
>> https://admin.fedoraproject.org/updates/FEDORA-2015-5723/firefox-37.0.1-1...
>>
>> The currently available version of Firefox in Fedora 20 has a critical
>> vulnerability which allows a man-in-the-middle attacker to impersonate any
>> HTTPS website. In this context, shouldn't security concerns win out over the
>> worry that there might be some regression? We already know there's a serious
>> problem in the current package, so why do we have to wait 14 days just
>> because there might be some problem in the new package?
>>
>> Shouldn't this policy be revised?
>
>I thought a packager already has the ability to push something to
>stable without any delay? It's just not the default. Is that
>incorrect?
>
>I think in the case of an upstream like FireFox where we can pretty
>much be assured that they've escalated a critical security update
>before any other pending updates, that it's completely reasonable for
>the packager to take advantage of any policy that lets them bypass
>updates-testing.
I don't know whether that's correct or not. If it is true, Stransky, could you take that approach in future instances?
In any case, this is not an issue specific to one particular update or one particular maintainer. Perhaps there should be a checkbox for "this is a security update ONLY" that would allow an update to bypass the updates testing repository?
9 years
Summary/Minutes from today's FPC Meeting (2015-04-16 16:00 - 17:25 UTC)
by James Antill
======================
#fedora-meeting-1: fpc
======================
Meeting started by geppetto at 16:01:45 UTC. The full logs are available
at
http://meetbot.fedoraproject.org/fedora-meeting-1/2015-04-16/fpc.2015-04-...
.
Meeting summary
---------------
* Roll Call (geppetto, 16:01:45)
* #524 static UID for ceph (geppetto, 16:12:49)
* LINK: https://fedorahosted.org/fpc/ticket/524 (geppetto, 16:12:55)
* ACTION: A link/summary of the upstream discussion of how this will
be used, might be nice. Currently split on how this is useful.
(geppetto, 16:40:57)
* #522 Should -static packages require -devel (geppetto, 16:41:24)
* ACTION: was voted on last week, and policy changed. (geppetto,
16:48:06)
* #515 Bundling determination and exception request (geppetto,
16:49:16)
* ACTION: Create a static. lib., decide among yourself who will own
it. Size exception is based on the bundling size (and xmlrpcpp is
big). (geppetto, 16:58:58)
* #520 [Guidelines Draft] Per-Product Configuration Defaults v2
(geppetto, 16:59:10)
* ACTION: sgallagh just do the macro change, and update the draft.
We'll vote on it next week. (geppetto, 17:13:59)
* #513 Use python -Es in shbang (geppetto, 17:14:06)
* Open Floor (geppetto, 17:17:19)
* LINK:
https://fedoraproject.org/wiki/User:Sgallagh/Per-Product_Configuration_Pa...
(sgallagh, 17:20:34)
Meeting ended at 17:25:49 UTC.
Action Items
------------
* A link/summary of the upstream discussion of how this will be used,
might be nice. Currently split on how this is useful.
* was voted on last week, and policy changed.
* Create a static. lib., decide among yourself who will own it. Size
exception is based on the bundling size (and xmlrpcpp is big).
* sgallagh just do the macro change, and update the draft. We'll vote on
it next week.
Action Items, by person
-----------------------
* sgallagh
* sgallagh just do the macro change, and update the draft. We'll vote
on it next week.
* **UNASSIGNED**
* A link/summary of the upstream discussion of how this will be used,
might be nice. Currently split on how this is useful.
* was voted on last week, and policy changed.
* Create a static. lib., decide among yourself who will own it. Size
exception is based on the bundling size (and xmlrpcpp is big).
People Present (lines said)
---------------------------
* tibbs|w (108)
* geppetto (93)
* zodbot (14)
* Rathann (12)
* sgallagh (11)
* racor (9)
* tomspur (6)
* rdieter (4)
* nirik (4)
* tibbs (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
9 years
Source files of official RPM packages
by Martin Cigorraga
Hello all,
I'm looking to contribute with my own packages through a Copr
repository so to start I would like to check out how others build
their own packages, where can I find the sources (metada, scripts and
other files) of the actual official RPM files?
I would like to start working with the applications I use every day to
provide latest versions of them and then gradually start building and
providing my own RPMs for applications and tools that aren't actually
shipped in the official repositories - and I wasn't unable to find on
any other 3rd-party repository.
Thank you very much for any advice you can provide :)
-Martín
9 years
%doc doesn't seem to use _defaultdocdir definition
by dani
Hi List,
I'm a newb at writing spec files, please bear with me.
I'm rebuilding a package for RHEL 6, so if this is the wrong list,
please let me know.
I have redefined the prefix stack:
%global _prefix /opt/%{name}/%{version}
%global _exec_prefix %{_prefix}
%global _bindir %{_exec_prefix}/bin
%global _sbindir %{_exec_prefix}/sbin
%global _libexecdir %{_exec_prefix}/libexec
%global _sysconfdir /etc
%global _sharedstatedir /var/lib
%global _localstatedir /var
%global _libdir %{_exec_prefix}/%{_lib}
%global _includedir %{_prefix}/include
%global _datarootdir %{_prefix}/share
%global _datadir %{_datarootdir}
%global _infodir %{_datarootdir}/info
%global _localedir %{_datarootdir}/locale
%global _mandir %{_datarootdir}/man
%global _docdir %{_datarootdir}/doc
%global _htmldir %{_docdir}
%global _dvidir %{_docdir}
%global _pdfdir %{_docdir}
%global _psdir %{_docdir}
%global _defaultdocdir %{_docdir}
In configure:
../configure \
--prefix=%{_prefix} \
--exec-prefix=%{_exec_prefix} \
--bindir=%{_bindir} \
--sbindir=%{_sbindir} \
--sysconfdir=%{_sysconfdir} \
--datadir=%{_datadir} \
--includedir=%{_includedir} \
--libdir=%{_libdir} \
--libexecdir=%{_libexecdir} \
--localstatedir=%{_localstatedir} \
--sharedstatedir=%{_sharedstatedir} \
--mandir=%{_mandir} \
--infodir=%{_infodir} \
--docdir=%{_docdir} \
...
In make install:
make DESTDIR=%{buildroot} \
prefix=%{_prefix} \
mandir=%{_mandir} \
infodir=%{_infodir} \
docdir=%{_docdir} \
install
The package completes without errors, resulting in RPMs, but In the
output I see multiple instances of:
+ DOCDIR=~/rpmbuild/BUILDROOT/<rpm top buildroot
dir>/usr/share/doc/%{name}-%{version}
+ export DOCDIR
and when installing the RPMs they install docs to /usr/share/doc.
when building and installing manually all is well (share/doc under /opt/...)
What am I doing wrong?
9 years
%license and directory ownership
by Jonathan Underwood
Hi,
Now that the guidelines recommend use of the %license tag,
fedora-review complains about the unowned directory
/usr/share/licenses. I presume this is something that needs fixing in
fedora-review, otherwise the fix would be for every package to Requre
the filesystem package ? Before filing a bug against fedora-review I
wanted to check that this analysis is correct.
Thanks,
Jonathan
9 years
Re: [Fedora-packaging] why gem install always use the --force option? [SOLVED]
by Athenas Jimenez
Thank you so much!!! That was exactly the answer I was looking for.
On Thu, Apr 2, 2015 at 2:30 AM, Vít Ondruch <vondruch(a)redhat.com> wrote:
> Dne 1.4.2015 v 19:14 Athenas Jimenez napsal(a):
>
> Hello,
>
> This is basically my question, why ruby gems packages always use --force
> option during installation?
>
> (from http://pkgs.fedoraproject.org/cgit/ruby.git/tree/macros.rubygems)
>
> gem install \\\
> -V \\\
> --local \\\
> --install-dir %{-d*}%{!?-d:.%{gem_dir}} \\\
> --bindir .%{_bindir} \\\
> *--force \\\*
> --document=ri,rdoc \\\
> %{-n*}%{!?-n:%{gem_name}-%{version}.gem} \
> %{nil}
>
> Thanks for your help
>
> Athenas
>
>
>
>
>
> From the help:
>
> $ gem help install
>
>
> -f, --[no-]force Force gem to install, bypassing
> dependency
> checks
>
>
>
> I.e. "gem install" would try to install also gem's dependencies (which are
> not available, since we are offline during build), while the "--force"
> option installs just the gem itself. The dependecies have to be satisfied
> by BuildRequires instead.
>
>
> Vít
>
>
> --
> packaging mailing list
> packaging(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/packaging
>
9 years
Merging 2 packages
by Scott Talbert
Hi,
I have two packages that I maintain that both use the same upstream
tarball. I'm not sure about the history behind why this was setup this
way, but I assume it was so that one could be updated without having to
update the other. This happens so rarely that I don't think it is really
worth the effort of maintaining two separate packages (and dealing with
buildroot overrides, submitting synchronized updates, etc.) Thus, I am
thinking about merging them. Is this really just as simple as having spec
A build spec B's packages and then retire source package B?
Thanks,
Scott
9 years
