Some orphaned packages

[Toshio Kuratomi]

As some of you may know from flock or following the FPC meeting minutes, I'm
taking a break from Fedora.  As part of that, I've reassigned most of my
packages to others that can  care for them.  A few packages don't have
obvious owners (mostly in specific branches) So I've orphaned them.  If
you'd like to pick them up, please go to the pkgdb and do so:

qbzr, bzr-explorer => orphan
gprof2dot => orphan
python-paver => orphan
python-elixir => (orphan Fedora devel, Fedora 21, Fedora 20, Fedora 19,
Fedora EPEL 5)
python-cpio => toshio (Doesn't update much so I could keep it but I'm not
using it so I'd be happy to give it to someone ele)
bzr-gtk => orphan (epel5)
bzr, bzrtools => orphan on epel5
python-cjson (el5) => orphan
python-migrate => orphan(el5)

-Toshio


pgpomFY24fCwY.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: Brokenness in newly created dist-git repositories

[Toshio Kuratomi]

On Tue, Jul 22, 2014 at 08:31:50PM +0100, Richard W.M. Jones wrote:
> 
> OK I see in the final comment there is a hang reported.  I would still
> be interested in whether anyone else can reproduce the bug on the
> specific two repos: ocaml-camlp4 & ocaml-labltk.
> 
Yep, I can reproduce on those two.  I notice that one of the comments on the
bug seems to indicate that this is happening on git repos that only have the
master branch so that might be a clue as to why these two new repositories
are the only ones you're seeing with the issue.

-Toshio


pgp5duj71FFrC.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: Brokenness in newly created dist-git repositories

[Toshio Kuratomi]

On Tue, Jul 22, 2014 at 08:11:30PM +0100, Richard W.M. Jones wrote:
> 
> Two new packages/repositories have been created for me recently.
> Both appear to be broken in a subtle, non-fatal way:
> 
>   $ fedpkg clone ocaml-camlp4
>   $ cd ocaml-camlp4/
>   $ fedpkg verrel
>   Exception AttributeError: '_read_only' in  > ignored
> 
> [ the command hangs for a few minutes before printing ... ]
> 
>   ocaml-camlp4-4.02.0-0.3.git87c6a6b0.fc22
> 
> The other repository which is broken in the same way is `ocaml-labltk'.
> 
> This doesn't happen for me on any other dist-git repository, so I
> don't believe it has anything to do with my copy of fedpkg or my
> environment.
> 
> I opened a bug about this but it didn't get any traction:
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1121333
> 
> I'm slightly worried that all new repos are being built incorrectly
> somehow.
> 
Looks to me like it's an aspect of this bug:

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



pgpx3awVxpKu3.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: Schedule for Thursday's FPC Meeting (2014-07-10 16:00 UTC)

[Toshio Kuratomi]

On Wed, Jul 9, 2014 at 12:31 PM, James Antill  wrote:
>  Following is the list of topics that will be discussed in the FPC
> meeting Thursday at 2014-07-10 16:00 UTC in #fedora-meeting-1 on
> irc.freenode.net.
>
>
>  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.

There were a couple other tickets that are needed for Fedora Changes
so we'll discuss those first thing:

Per-product Config:
https://fedorahosted.org/fpc/ticket/446

New java Packaging Guidelines (AFAIK, just making javadocs optional):
https://fedorahosted.org/fpc/ticket/445


There were some updated to the mimeinfo scriptlets that we passed last
week as well.  So we could take a look at that while it's still fresh
in our minds:
https://fedorahosted.org/fpc/ticket/440

-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

Re: [Env and Stack WG] cancelled meeting

[Toshio Kuratomi]

On Fri, Jun 20, 2014 at 03:38:32PM +0200, Marcela Mašláňová wrote:
> On 06/16/2014 06:40 PM, Toshio Kuratomi wrote:
> >On Mon, Jun 16, 2014 at 05:52:18PM +0200, Marcela Mašláňová wrote:
> >>Meetings will be cancelled until we have some topics to discuss. If
> >>you have something, please let us know on mailing list:
> >>env-and-sta...@lists.fedoraproject.org
> >>
> >On item for a meeting agenda would be finding replacement members for the
> >two open seats.
> >
> >-Toshio
> >
> >
> >
> That's great for agenda, but I don't see any want to be members. I
> guess docker people should also join Env and Stack WG. Any takers?
> 
> Let's meet next week, see progress of features and discuss open seats.
> 
Probably should publish that there's two open seats to the devel list and ask
for candidates to step forward.

-Toshio


pgpuoV9ijOLRj.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: Cross-distro fossology instance?

[Toshio Kuratomi]

On Mon, Jun 16, 2014 at 10:01:09AM +0200, Stanislav Ochotnicky wrote:
> 
> I was wondering if anyone was considering cross-distribution fossology[1]
> instance where we could share burden of license review with other
> distros. I know at least Debian does comprehensive license reviews and
> we could possibly deduplicate a lot of review time this way.
> 
> Note that I am not talking about doing whole package reviews in
> fossology, just hooking up the license checking part there.
> 
> It's likely we'd need to clean up fossology a bit to be universally
> usable for this use case, but it should be doable. Opinions,
> suggestions...all welcome.
> 
> [1] http://fossology.org/
>
Probably should get Fedora Legal's opinion here too.

I'm not sure I'd like the idea of having the work of license review done by
third parties.  I think it might be better to do reporting to fossology.
ie: we do license review and Debian also does license review and we
coordinate by posting our results to fossology.

The reason is that I've seen a lot of missed license problems both in Fedora
packages and in Debian packages.  Coordinating more eyes on the problem
seems like a way to fix this while deduplicating just means we'll all be
sharing the same erroneous assumptions.

-Toshio


pgpTg3DSbxKZ0.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: [Env and Stack WG] cancelled meeting

[Toshio Kuratomi]

On Mon, Jun 16, 2014 at 05:52:18PM +0200, Marcela Mašláňová wrote:
> Meetings will be cancelled until we have some topics to discuss. If
> you have something, please let us know on mailing list:
> env-and-sta...@lists.fedoraproject.org
> 
On item for a meeting agenda would be finding replacement members for the
two open seats.

-Toshio


pgp2o8CjQLpBU.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: Schedule for Wednesday's FESCo Meeting (2014-06-11)

[Toshio Kuratomi]

On Wed, Jun 11, 2014 at 11:35:16AM -0400, Josh Boyer wrote:
> On Wed, Jun 11, 2014 at 9:36 AM, Toshio Kuratomi  wrote:
> > 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/fesco,
> > 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.
> 
> Should probably discuss Bill's departure and how you want to handle
> the open seat.
> 
I'll make sure this comes up in the meeting and I'll open a ticket if
we don't just select a runner-up from the previous election as per
http://fedoraproject.org/wiki/FESCo_election_policy#Filling_Vacant_Seats

-Toshio


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

Schedule for Wednesday's FESCo Meeting (2014-06-11)

[Toshio Kuratomi]

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 17: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 '2014-06-11 17:00 UTC'


Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1221 Product working group activity reports
.fesco 1221
https://fedorahosted.org/fesco/ticket/1221

= New business =

#topic #1311 Disable syscall auditing by default
.fesco 1311
https://fedorahosted.org/fesco/ticket/1311

#topic #1310 Reconsidering rpcbind's exception allowing it to start by default
.fesco 1310
https://fedorahosted.org/fesco/ticket/1310

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

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/fesco,
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. 

-Toshio


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

This Weeks FESCo Meeting: Cancelled

[Toshio Kuratomi]

Sorry for the late notification.  I took a look at making an agenda for this
week and saw that we only have a few tickets to look at and all of them
are pending input from various other people so I'm cancelling the meeting.

That's two week's in a row so plan on having a meeting next week.  We should
hopefully have information back from maintainers on a few tickets and WG
activity reports among others.

-Toshio


pgpxdI3ls89NN.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: Fwd: Ophaning lcms(1)

[Toshio Kuratomi]

https://apps.fedoraproject.org/packages/lcms/bugs/all lists a CVE.  If
lcms-11 is no longer going to be maintained in Fedora that (and any
other) security flaws won't be addressed.  It's therefore advisable
for them to update to the new version of lcms if feasible.  The
affected packager would likely want to take ownership of lcms-1 and
patch the security issues.

-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

Re: Fwd: Ophaning lcms(1)

[Toshio Kuratomi]

On Mon, Jun 02, 2014 at 10:39:56PM +0200, Nicolas Chauvet wrote:
> python-pillow-2.2.1-4.fc20.src.rpm
>
This one can be fixed by upgrading to 2.3.0 (or greater.  2.4.0 is current).
2.4.0 is what's in rawhide.  Not sure if that's safe to push back to f20 and
earlier.  (Although I see that there's an insecure use of tempfile CVE that
was ficed in 2.3.1 so maybe it makes sense to update even if there is API
breakage.)

@smani: Do you have more information here?

-Toshio


pgpVtProWXg4E.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: Packaging: bin subfolder

[Toshio Kuratomi]

On Thu, May 29, 2014 at 11:56:02PM +0200, Sandro Mani wrote:
> 
> >>binaries and python scripts to the /usr/bin/salome folder. Is this
> >>acceptable?
> >   I believe a symbolic link should be acceptable. Actually creating a subdir
> >would probably have a lot of opposition, but it should be possible to
> >reconfigure salome to use %_libexecdir/salome or %_libdir/salome
> Yeah reconfiguring is not an issue, and if the symlink solution is
> accepted I'd be happy. I'd just prefer not to break the install
> hierarchy too much so that various documentation and stuff on the net
> also applies to Fedora as far as possible.
> 
  Probably %{_libdir}/salome/REAL_FILES  and
%{_bindir}/SYMLINKS_TO_REAL_FILES.  If there is a concern that salome's
files will conflict with other things in %{_bindir} the symlinks probably
need to have a prefix like salome-SYMLINK.

-Toshio


pgpjAguzoXqEg.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: [Fedora-packaging] Schedule for Thursday's FPC Meeting (2014-05-29 16:00 UTC)

[Toshio Kuratomi]

On Wed, May 28, 2014 at 05:30:12PM -0400, James Antill wrote:
>  Following is the list of topics that will be discussed in the FPC
> meeting Thursday at 2014-05-29 16:00 UTC in #fedora-meeting-1 on
> irc.freenode.net.
> 
>  Local time information (via. rktime):
> 
> 2014-05-29 09:00 Thu US/Pacific PDT
> 2014-05-29 12:00 Thu US/Eastern EDT
> 2014-05-29 16:00 Thu UTC <-
> 2014-05-29 17:00 Thu Europe/London  BST
> 2014-05-29 18:00 Thu Europe/Paris  CEST
> 2014-05-29 18:00 Thu Europe/Berlin CEST
> 2014-05-29 21:30 Thu Asia/Calcutta  IST
> --new day--
> 2014-05-30 00:00 Fri Asia/Singapore SGT
> 2014-05-30 00:00 Fri Asia/Hong_Kong HKT
> 2014-05-30 01:00 Fri Asia/Tokyo JST
> 2014-05-30 02:00 Fri Australia/Brisbane EST
> 
I'm afraid I won't be able to make the meeting tomorrow.  My stepchildren's
father's flight was delayed and I'll have to pick him up at the airport
tomorrow morning.

spot or geppetto, would either of you be able to run the meeting tomorrow?

I can vote in ticket after I get back from the airport.

-Toshio


pgpS9aDTiHfhQ.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: Schedule for Wednesday's FESCo Meeting (2014-05-28)

[Toshio Kuratomi]

On Wed, May 28, 2014 at 11:06:03AM -0400, Matthew Miller wrote:
> On Wed, May 28, 2014 at 11:05:10AM -0400, Stephen Gallagher wrote:
> > This ticket appears to be resolved on Trac. Shall we just cancel the
> > meeting this week?
> 
> I was trying to think of something inflammatory, but I don't think I have it
> in me today. :) I'm good with canceling.
>
I don't see any new tickets or any requests to add something to the agenda
so consider this meeting cancelled.  See you all next week.

-Toshio


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

Schedule for Wednesday's FESCo Meeting (2014-05-28)

[Toshio Kuratomi]

Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 17: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 '2014-05-28 17:00 UTC'


Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

#topic #1291 F21 System Wide Change: BerkeleyDB 6 - 
https://fedoraproject.org/wiki/Changes/BerkeleyDB_6
.fesco 1291
https://fedorahosted.org/fesco/ticket/1291

= New business =

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

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/fesco,
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. 


-Toshio


pgpNG3h5Bl9FT.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: Fwd: git commit Undelivered Mail Returned to Sender

[Toshio Kuratomi]

On Thu, May 15, 2014 at 08:35:27PM -0400, Al Dunsmuir wrote:
> On Thursday, May 15, 2014, 12:42:25 AM, Orion Poplawski wrote:
> > More fallout from pkgdb2?
> 
Yeah.  The script that updates the package email aliases was still pointing
at the staging instance (for testing).  So it wasn't picking up new
packages.  I've changed the script, run it once manually, and it seems to
have created the octave-io-owner email alias as expected.

> I  just  send  an  email to this list about weird problems I have been
> experiencing  with  the  ppc  mailing  list. When I tried to log on to
> check  my  options, I got a 502 proxy error about a DNS lookup failure
> for "collab03.fedoraproject.org".
> 
I think that's unrelated.

-Toshio


pgpIZMte1XxCP.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: Attempting to contact three unresponsive maintainers

[Toshio Kuratomi]

On Thu, May 15, 2014 at 03:57:24PM +0530, Kashyap Chamarthy wrote:
> On Fri, Mar 28, 2014 at 10:11:47AM -0700, Toshio Kuratomi wrote:
> > Greetings, we've been told that the email addresses for three package
> > maintainers are no longer valid.  I'm starting the unresponsive maintainer
> > policy to find out if they are still interested in maintaining their
> > packages (and if so, have them update their email addresses in FAS).  If
> > they're not interested in maintaining or we can't locate them I'll have
> > FESCo orphan the packages so that others can take them over.
> > 
> > If you have a way to contact any of these maintainers, please let them know
> > that we'd appreciate knowing what to do with their packages.  Thanks!
> > 
> > Maintainers:
> > * awnuk -- former email address aw...@redhat.com
> 
> He doesn't work for Red Hat anymore. I CC'ed Ade Lee who leads upstream
> Dogtag work, he might suggest someone who is willing to take up the
> maintenance.
> 
Thanks.  do note that the dogtag stuff has a maintainer.  awnuk was just
a comaintainer.

Sometimes when people leave red hat they still want to maintain their Fedora
packages (or a subset thereof).  Other times they want to give them up
because they only maintained them as part of their job.  If we definitely
know that one of these cases apply we can do something appropriate with
package ownership and account info (in the former case, the person needs to
update their email address in the Fedora Account System.  In the latter case
we can remove their acls in the Fedora PackageDB).  In many cases, like this
one, we just know that the packager has left red hat and don't know what
they wish to do.  That leaves us with packages where we suspect that the bug
reports, commit messages, etc are going to someone who isn't actually
working on the packages.  We'd like to know what's happening so that we can
update the acls to reflect who's actually actively working on the packages.

-Toshio


pgpgGMIiT5XCx.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: Attempting to contact three unresponsive maintainers

[Toshio Kuratomi]

On Tue, Apr 08, 2014 at 01:30:27PM +0200, Ondrej Vasik wrote:
> 
> If you don't find any contact for llim, feel free to reassign redhat-lsb
> to me - I'm monitoring the bugzillas of redhat-lsb package anyway and
> I'm the owner in RHEL. We discussed with Lawrence transfer even in
> Fedora, but it never happened.
> 
A little late but this has been done now.  Thanks for taking it.

-Toshio


pgpv5YcOgv06F.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: Incorrect order of /usr/bin and /usr/sbin in path

[Toshio Kuratomi]

On Mon, May 05, 2014 at 10:38:10PM +0200, Kalev Lember wrote:
> On 05/05/2014 10:28 PM, Matthew Miller wrote:
> > On Mon, May 05, 2014 at 04:24:03PM -0400, Matthias Clasen wrote:
> >> It causes pointless configure and Makefile complications in every single
> >> upstream project that wants to install something into that location and
> >> has to differentiate between Fedora (/usr/libexec) and the rest of the
> >> world (/usr/lib/$pkg). It has ripple-on effects throughout the project -
> >> e.g. having to patch the right prefix into desktop files, into service
> >> files, etc etc.
> > 
Note that when I first read this, I assumed you meant %{_libexecdir} and
%{_libdir}/$pkg which would be untrue.  After reading kalev's message, I'm
guessing that you mean %{_libexecdir} and %{_prefix}/lib/$pkg.  This could
also be stated as %{_libdir}/$pkg vs %{_prefix}/lib/$pkg... %{_libexecdir}
and %{_libdir}/$pkg are both valid in the packaging guidelines.

> > Now that's a practical reason that I can get behind. But given that we're
> > already here and have done all that, is it valuable to undo? Again, I shrug
> > -- plenty of other stuff to fix, but I think a case could certainly be made.
> 
> I don't think it's valuable to undo it at this point, but rather let
> applications install into /usr/lib/$pkg/ if they want to. Right now, the
> Fedora guidelines downright forbid that.
> 
> I'll emphasize that I really mean /usr/lib/$pkg/, as opposed to
> /usr/$multilib_directory/$pkg/ -- this ensures that the same directory
> is available in all distros the same way, and avoids multilib issues
> with helper binaries.
> 
> Right now, various upstreams have to ship checks like:
> 
> if (fedora_based_distro)
>   helper_dir = /usr/libexec
> else
>   helper_dir = /usr/lib
> 

If upstream is using the autotools you should just use @pkglibexecdir@ or
@libexecdir@.  Linux distributions, BSDs and etc all set --libexecdir to
the proper location for their tastes.

If upstream does not use autotools then they may end up having to do
a platform check for helper_dir.  But they could also end up having to do
a platform check for shared libraries or arch-specific data files. The
difference between Fedora and other distros is really multilib, not libexec.

> Relaxing the guidelines would allow those upstreams to write saner code,
> and be more compatible across various distributions.

If we get rid of multilib then that would be fine otherwise it'll be more
error prone to add %{_prefix}/lib into the mix with  %{_libexecdir} and
%{_libdir}.  Most upstreams do not know about or care about multilib.  This
means that they mix stuff appropriate for %{_prefix}/lib/$pkg in with things
that must go in %{_libdir}/$pkg.  As long as we have multilib we need to
check the usage of these directories and patch in the separation between the
directories when needed.  The usage of %{_libdir}/$pkg and %{_libexecdir}
just makes this more apparent.

We've already gotten rid of multilib distinctions for specific ecosystems
within Fedora so they don't have to make checks like this.  We could either
expand that to encompass additional specific ecosystems or we could get rid
of multilib altogether.

-Toshio


pgpJ1pDGlvtN4.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: EPEL Python 3.4 for 7

[Toshio Kuratomi]

On Sat, Apr 26, 2014 at 09:13:12PM -0600, Orion Poplawski wrote:
> On 04/26/2014 06:55 PM, Toshio Kuratomi wrote:
> > 
> > On Apr 26, 2014 11:37 AM, "Orion Poplawski"  > <mailto:or...@cora.nwra.com>> wrote:
> > 
> >> One interesting change from RHEL7 beta->rc is the dropping of libdb4
> >> which python3 currently BRs, although I cannot see any evidence in
> >>
> > http://kojipkgs.fedoraproject.org//packages/python3/3.4.0/2.fc21/data/logs/x86_64/build.log
> >> of python3 actually using it (it seems to be using gdbm instead).
> >>
> > Python 3 does use libdb although I think it can use libdb5.  Python has
> > a standard library that includes both libdb bindings and gdbm bindings.
> 
> Hmm, I see no evidence that it makes use of both as currently built.  It
> seems that gdbm is preferred and there are no dependencies on libdb*.
> 
On further investigation, I see that you are absolutely right.  The bsddb
module was removed from python3.0 so we can remove the BuildRequires on db
for any python3 packages.

See the disclaimer at the top of the python2 docs:
https://docs.python.org/2/library/bsddb.html

and the PEP:
http://legacy.python.org/dev/peps/pep-3108/#maintenance-burden

-Toshio


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

Re: EPEL Python 3.4 for 7

[Toshio Kuratomi]

On Mon, Apr 28, 2014 at 01:45:52PM -0400, Aaron Knister wrote:
> I think it's a little unrealistic to expect the vendor to namespace their
> packages although it would be nice and probably the right thing to do.
>
If you buy from Red Hat, you should complain to them.  That might have more
effect than I have had.

> Could
> EPEL, as the 3rd-party layered product,  namespace theirs? (e.g.
> epel-python34). It's more consistent with how other packages store version
> numbers in the name

Unfortunately, this wouldn't be very consistent with the packages as
a whole.  If you have a bug in the python3 package that's in
/usr/bin/python3.4, for instance, you're going to go to bugzilla looking to
file against the python34 package, not epel-python34.  And we'd be doing
this for packages that we don't even build against or assume that people
have.  We also have no control over what packages Red Hat will choose to
scl-ize.  In the future, they could create mediawiki119 scls or Turbogears2
scls.  So we really need Red Hat to stick to convention and not pollute the
toplevel package 


> (although as an aside, the smushing together of version
> numbers without dots drives me a little crazy so part of me likes the dot in
> python3.4).
>

I also like the dot in the version number in the name.  However, although
that solves the problem of conflicting package names for a computer, it
doesn't solve the problem for humans.  (Why do I have both python3.4 and
python34 packages installed?  I should be able to get rid of one of those.)
It's also not a requirement of scls that they do not contain any dots in the
scl name.  Future Red Hat supplied scls may put a dot into the name and thus
we'll still have conflicts.

-Toshio


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

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Toshio Kuratomi]

On Apr 28, 2014 5:01 PM, "Daniel J Walsh"  wrote:
>
> The problem  is lots of services require systemd because they ship a
> unit file and want systemctl reload to happen.

Would removing the requires on systemd and doing:

/usr/bin/systemctl reload ||:

Work for these cases?

-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

Re: F21 System Wide Change: SCL

[Toshio Kuratomi]

On Thu, Apr 17, 2014 at 04:35:25PM +0200, Miloslav Trmač wrote:
> 2014-04-14 14:13 GMT+02:00 Jaroslav Reznik :
> 
> 2. Upload packages into git - specific branch based on Fedora version and
> name
> of collection. For stable repo we must be able to replicate builds from 
> git
> repo, which Fedora own.
> 
> 
> I'm confused; what precisely is the layout you are proposing for pkgs git?  I
> read this as ruby.git/{f20,f21,f21-$sclname}; is that really the proposal?

I'm not sure what the proposal is but the FPC wants to have all scls live in
a separate package than the "mainstream" package.  Like this:

ruby.git/{f20,f21}
fdr-ruby1.9.3-ruby.git/{f20,f21}

This matches with what mingw does and after working on creating an SCL, it
seems to be a better plan to keep the two sources separate as scl spec files
are much different than mainstream specs.

-Toshio


pgp1QXELqWbXO.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: Schedule for Thursday's FPC Meeting (2014-04-17 16:00 UTC)

[Toshio Kuratomi]

I won't be present again this week (or next) but I did vote on a few
tickets.  Hopefully that will help with meeting, discussing, and voting.

-Toshio


pgpKd0BmNZ4y9.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: Python 3 and mod_wsgi

[Toshio Kuratomi]

On Mon, Apr 14, 2014 at 04:54:33PM -0400, Bohuslav Kabrda wrote:
> ━━━
> 
> I naively ported my Django app to Python 3 and didn't realize WSGI was
> going to be an issue.  I saw python3-django was available for Fedora 20 
> and
> thought I was all set until I saw in my httpd logs that python2.7 seems to
> be the assumed default for mod_wsgi.  After reading the README and more, I
> see the writing on the wall:
> 
> """
> If you have multiple versions of Python installed and you are not using
> that which is the default, you may have to organise that the PATH 
> inherited
> by the Apache application when run will result in Apache finding the
> alternate version. Alternatively, the WSGIPythonHome directive should
> be used to specify the exact location of the Python installation
> corresponding to the version of Python compiled against. If this is not
> done, the version of Python running within Apache may attempt to use the
> Python modules from the wrong version of Python.
> """
> 
> I take this to mean that merely fiddling with WSGIPythonHome alone will be
> insufficient and that I would need to recompile the package.  Is that
> correct, or did I miss a Python3-specific mod_wsgi package or some other
> neater solution?  If I am truly forced to recompile -- as reversing the
> Python 3 is really undesirable at this point -- is there any reason Fedora
> couldn't have two mod_wsgi packages (one for Python2 and another for
> Python3)?
> 
> AFAIK you can't have 2 mod_wsgi's, each one compiled against a different 
> Python
> major.minor, loaded by Apache at the same time for various reasons. So the 
> best
> solution would IMO be to create python3-mod_wsgi (subpackage of mod_wsgi), 
> that
> would conflict with mod_wsgi. It should be perfectly doable and it shouldn't
> break anything.
> CCing Matthias, the owner of mod_wsgi in Fedora - Matthias, what do you think?
> 

It's available in rawhide already and uses the conflicts that you outline:
http://koji.fedoraproject.org/koji/buildinfo?buildID=493296
https://bugzilla.redhat.com/show_bug.cgi?id=1007002

However, conflicts aren't the correct strategy here.

Instead, take a look at how the python26-mod_wsgi package is implemented for
epel5.  The two mod_wsgi packages should be parallel installable.  But the
apache config files should prevent both from being loaded into a single
apache process.  Here's the config file for the python26-mod_wsgi package
as a example of this:

  # NOTE: By default python26-mod_python with not load if mod_wsgi is
  # installed and enabled.  Only load if mod_python and mod_wsgi are not
  # already loaded.

  
LoadModule wsgi_module modules/python26-mod_wsgi.so
  

We should probably have a similar guard in the mod_wsgi config file as well.
Then be sure that we consciously name the conf files so that we are
promoting one of these as the default (because sort order will load one of
them before the other) if both packages are installed.

Having both packages be parallel installable makes it easier for people
who are willing to configure apache to start two separate instances of
apache.  The two instances could each run a different version of mod_wsgi by
adding the correct mod_wsgi config for each.

Bug filed:
https://bugzilla.redhat.com/show_bug.cgi?id=1087943

-Toshio


pgp04t4ERgkAq.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: Agenda for Env-and-Stacks WG meeting (2014-04-08)

[Toshio Kuratomi]

On Tue, Apr 08, 2014 at 01:26:23PM -0400, Matthew Miller wrote:
> On Tue, Apr 08, 2014 at 06:02:02AM -0700, Toshio Kuratomi wrote:
> > not sure that the ruby scl should have its own change.  It needs to have
> 
> FWIW, I'm happy to have a distinct change because I want to call this out in
> the marketing.
> 
Note -- I called out the need to talk to the docs and marketing team in my
email because I think that we'll probably want to publicize all SCLs so the
SCL approval process should probably also get something into the docs and
marketing queue.  A separate Fedora Change might be extraneous in this
regard -- I'm thinking that fesco probably doesn't need to re-approve
an SCL  that FPC has already approved.

OTOH, how does the Cloud SIG want to use the SCL?  If they want to create
things that are outside of the SCL that make use of it, that would seem to
be a point of coordination and thus would be Fedora Change worthy... On yet
another hand, though, having something not in an SCL depend on something
that's in an scl was something that I was told we (FPC) shouldn't put into
the first draft of the guidelines.  Instead things that require SCLs must be
placed inside of an SCL.

I guess -- there needs to be a bit more information about what is desired
here to know whether that would require a rethink of some of the
foundational goals that were given to me.

-Toshio


pgpk0MH6aPNBK.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: Agenda for Env-and-Stacks WG meeting (2014-04-08)

[Toshio Kuratomi]

On Tue, Apr 08, 2014 at 04:16:58PM +0200, Marcela Mašláňová wrote:
> On 04/08/2014 03:02 PM, Toshio Kuratomi wrote:
> >
> >not sure that the ruby scl should have its own change.  It needs to have
> >the equivalent filed for the fpc to evaluate, though.
> >https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#SCL_Approval_Process
> >
> >Since the guidelines aren't final, probably open an fpc ticket so the
> >fpc sees the request and more that it's needed for the fedora scl
> >change.  Although the scl package guidelines aren't final, the
> >guidelines/criteria for approving the scl itself were approved so fpc
> >should be able to evaluate it in parallel to finishing the packaging
> >guidelines.
> >
> >If we remove the ruby scl change we should add more to the main scl
> >change, though, about expectations around the scl approval.  For
> >instance, we probably want to touch base with docs/marketing to see if
> >they want to publicize scls in the exact same way as fedora changes or
> >have a slightly different procedure.
> >
> >Also note, in case no one saw it in either fpc or fesco meeting notes,
> >I'm traveling to a week and a half conference now followed by a week and
> >a half of vacation.so I likely won't be around for any fedora meetings
> >until april 27th (and playing catch up with my email for that first week.)
> >
> >-Toshio
> >
> >
> >
> I'm trying to provide feature needed by Cloud WG, that's all. I can
> file a new ticket on FPC, but wouldn't it just duplicate
> communication about General SCL guidelines?
> Ruby193 could test workflow around SCL in Fedora, that's another good
> reason to try how far can I get it and what won't work :)
> 
> I would prefer to keep my changes as is and let FESCo decide.
> 
I sense a miscommunication here -- the Draft Guidelines for approving an SCL
say that you need to get the FPC to approve new SCLs:

https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29#SCL_Approval_Process

I felt that a new FPC ticket would be good because this is the first SCL to
be approved and the FPC likely won't become aware of it unless it's called
out in a ticket.

-Toshio


pgpgC8BnX1shb.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: Agenda for Env-and-Stacks WG meeting (2014-04-08)

[Toshio Kuratomi]

On Apr 7, 2014 10:28 AM, "Marcela Mašláňová"  wrote:
>
> WG meeting will be at 16:00 UTC, 17:00 Central Europe, 12:00 (noon)
Boston, 9:00 San Francisco, 1:00 Tokyo in #fedora-meeting on Freenode.
>
> == Topic ==
> I sent three Change proposals. If you have any comments, please share
them.
> * https://fedoraproject.org/wiki/Changes/SCL
> * https://fedoraproject.org/wiki/Changes/Playground_repository
> * https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL
>
not sure that the ruby scl should have its own change.  It needs to have
the equivalent filed for the fpc to evaluate, though.
https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_(draft)#SCL_Approval_Process

Since the guidelines aren't final, probably open an fpc ticket so the fpc
sees the request and more that it's needed for the fedora scl change.
Although the scl package guidelines aren't final, the guidelines/criteria
for approving the scl itself were approved so fpc should be able to
evaluate it in parallel to finishing the packaging guidelines.

If we remove the ruby scl change we should add more to the main scl change,
though, about expectations around the scl approval.  For instance, we
probably want to touch base with docs/marketing to see if they want to
publicize scls in the exact same way as fedora changes or have a slightly
different procedure.

Also note, in case no one saw it in either fpc or fesco meeting notes, I'm
traveling to a week and a half conference now followed by a week and a half
of vacation.so I likely won't be around for any fedora meetings until april
27th (and playing catch up with my email for that first week.)

-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

Re: F21 System Wide Change: lbzip2 as default bzip2 implementation

[Toshio Kuratomi]

On Thu, Apr 03, 2014 at 04:48:03AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Apr 02, 2014 at 07:26:59PM -0700, Toshio Kuratomi wrote:
> > On Wed, Apr 02, 2014 at 08:47:11PM -0500, Chris Adams wrote:
> > > 
> > > I think the "right" way to move forward is to make a library that is at
> > > least API-compatible with the current libbz2.so.1, make all the tools
> > > use it, and just replace bzip2 with lbzip2.
> > >
> > Although I'm still on the fence about whether I'd vote for the Change as is,
> > I tend to agree with this sentiment.
> > 
> > Having two sets of code with different characteristics seems like
> > isomething of a disservice to users (I started bzip'ing my logs and backups
> > because the performance was suitable for my task when I tested with
> > /usr/bin/bzip2 but then when I operated on those logs with a custom python
> > script it was 3x slower!)
> > 
> > From past precedent I agree that getting the new package to the point where
> > we think it's a suitable replacement and then just making the switch for the
> > next release makes the most sense.
> I agree that this is desirable. OTOH, lbzip2.rpm is 90k, so I guess we can
> suffer the extra disk usage :)
> 
If it was about disk usage :-)

But it's not.  It's about having two codebases that do the same thing in
different ways.

-Toshio


pgp5MTiU5Fmrw.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: lbzip2 as default bzip2 implementation

[Toshio Kuratomi]

On Wed, Apr 02, 2014 at 08:47:11PM -0500, Chris Adams wrote:
> 
> I think the "right" way to move forward is to make a library that is at
> least API-compatible with the current libbz2.so.1, make all the tools
> use it, and just replace bzip2 with lbzip2.
>
Although I'm still on the fence about whether I'd vote for the Change as is,
I tend to agree with this sentiment.

Having two sets of code with different characteristics seems like
isomething of a disservice to users (I started bzip'ing my logs and backups
because the performance was suitable for my task when I tested with
/usr/bin/bzip2 but then when I operated on those logs with a custom python
script it was 3x slower!)

From past precedent I agree that getting the new package to the point where
we think it's a suitable replacement and then just making the switch for the
next release makes the most sense.

-Toshio


pgp1_BNd0eyBq.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: Meeting minutes from Env-and-Stacks WG meeting (2014-04-01)

[Toshio Kuratomi]

On Tue, Apr 1, 2014 at 6:39 AM, Marcela Mašláňová  wrote:
>
> * Open Questions - Playground: Signing  (mmaslano, 12:04:12)
>
I saw that this got voted on in the meeting even though it didn't get
recorded as such for the meeting minutes.  The proposal seemed to be:
use obs-sign to sign packages.  That's not actually a proposal that we
can approve here.  The proposal here should probably be: "is signing
of packages a blocker for making the playground repo, nice to have, or
optional?"

In terms of how to get the packages signed, that's something that the
infrastructure team has to decide.  IIRC past conversations correctly,
adding another signing server (meaning a different code base) to
infrastructure is at the bottom of their list of ways to sign packages
in copr (and by extension in the playground repo).

When I saw the vote in the meeting logs I mentioned it to nirik.  In
turn he told me that he hadn't heard anything about this and had only
glanced briefly at obs-sign (mentioning that it wasn't even packaged
for Fedora yet).  As I related to tjanez on IRC today, I think lack of
packaging probably slows down infra's ability to deploy it but is only
a foottnote to the real problems.  Compromising signing servers and
gaining access to the private keys on them is a very high value target
for an attacker.  The more signing servers we have the greater the
attack surface infrastructure has to protect.  probably in the ideal
scenario infra would run a single signing server and everything
needing signing would be sent to that.  (Jesse Kating had that use in
mind when he designed sigul but I don't know if that design goal
actually became part of the software that we are currently running).
A step down from there might be running multiple instances of the same
signing software to handle the various needs as infra would then have
to protect the keys on these multiple hosts.  At the bottom of the
list is running separate signing software as that places the
additional burden of auditing and protecting the software stack of the
multiple signing servers.

For whoever is going to approach infra about signing the packages in
copr it probably makes more sense to either talk about enhancing sigul
to work with copr or getting obs-sign to be able to sign packages from
koji.  We'd probably also want to ask bressers or someone else from
the security team to do some sort of evaluation of the code bases that
we're looking at.

-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

Re: [Fedora-packaging] Schedule for Thursday's FPC Meeting (2014-04-03 16:00 UTC) (post DST change UTC time)

[Toshio Kuratomi]

On Wed, Apr 02, 2014 at 04:20:16PM -0400, James Antill wrote:
> 
> (too big to fail vote?)
> #topic #391 Exception for bundled libraries in icecat
> .fpc 391
> https://fedorahosted.org/fpc/ticket/391
> 

Yep, there's four separate new exception criteria posted on:
https://fedoraproject.org/wiki/User:Toshio/Bundling_relaxation

that we can cote for.

> 
> #topic #411   proposal: migrate license files to %license instead of %doc
> .fpc 411
> https://fedorahosted.org/fpc/ticket/411
> 
> #topic #412   Please change the packaging guidelines to include
> packaging policy regarding systemd timer units
> .fpc 412
> https://fedorahosted.org/fpc/ticket/412
> 
These two are part of Fedora Changes/fedora.next so we'll probably move them
up in the schedule.

-Toshio


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

Attempting to contact three unresponsive maintainers

[Toshio Kuratomi]

Greetings, we've been told that the email addresses for three package
maintainers are no longer valid.  I'm starting the unresponsive maintainer
policy to find out if they are still interested in maintaining their
packages (and if so, have them update their email addresses in FAS).  If
they're not interested in maintaining or we can't locate them I'll have
FESCo orphan the packages so that others can take them over.

If you have a way to contact any of these maintainers, please let them know
that we'd appreciate knowing what to do with their packages.  Thanks!

Maintainers:
* awnuk -- former email address aw...@redhat.com
  - comaintainer of dogtag-pki, dogtag-pki-theme, pki-console, pki-core,
pki-ra, and pki-tps
* llim -- Lawrence Lim -- former email address l...@redhat.com
  - Bugzilla owner of redhat-lsb
* osier -- Osier Yang -- former email address jy...@redhat.com
  - comaintainer of libvirt

If we get to the point of removing acls for these people, only redhat-lsb
will need a new owner.  The other packages just have these package
maintainers as comaintianers.

-Toshio


pgpMjXb1h8e6a.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: Schedule for Thursday's FPC Meeting (2014-03-27 17:00 UTC) (next week back to 16:00 UTC)

[Toshio Kuratomi]

On Wed, Mar 26, 2014 at 09:45:14PM +0100, Miloslav Trmač wrote:
> 2014-03-26 20:51 GMT+01:00 James Antill :
> > (approval and retirement sections already passed, /opt exception passed)
> > #topic #339 software collections in Fedora
> > .fpc 339
> > https://fedorahosted.org/fpc/ticket/339
> 
> I can't help seeing this on the agenda for a long time (the ticket has
> been opened 7 months ago), including 3 months with no activity in the
> ticket, and now 2 months since last activity in the ticket.  Mailing
> list discussions also vary between vigorous in some months and
> essentially zero in other months.
> 
> Is there some work going on elsewhere that I'm missing?  If not, what
> are the constraints that prevent quicker decision making?
> Mirek

There have been many problems in the past which I think I've gone into
elsewhere.

Current things that are being worked on:

I have one set of scls built:
http://copr-fe.cloud.fedoraproject.org/coprs/toshio/SCL-Test-Python2.4/

Have to push the lessons from that into the guideline draft and also have to
update it with some more discussion that happened between Jan and myself
(after testing that those proposals will work).

Current build of scl-utils with patches I've found necessary applied:
http://copr-fe.cloud.fedoraproject.org/coprs/toshio/SCL-Test-scl-utils/

The filesystem paths patch from that is a blocker but seems to be stalled:
https://bugzilla.redhat.com/show_bug.cgi?id=105

The byte compile patch I have to work on incorporating some feedback from
Jan before trying to push it upstream.

I also need to build something that makes use of statefiles and conf files.
to test this out.  mariadb or a postgresql package are good candidates.
hhorak had mentioned testing this simply by changing the paths in a package
(rather than changing scl-utils) and the general strategy works.

That's pretty much where we're at.

-Toshio


pgpIZXS70xlFa.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: Let's close the remaining merge reviews

[Toshio Kuratomi]

On Mon, Mar 24, 2014 at 04:41:29PM -0400, Cole Robinson wrote:
> 
> An alternative would be to reassign every open merge review to the component
> in question, and let maintainers handle it as they like.
> 
> Thoughts?
> 
Alternative idea -- maybe identify all packages which are not ciritcal and
have an open merge review.  Take those packages out of the repository.

Then revisit the list and formulate a plan on what to do with thoes (even if
the plan is then, these were critical enough to leave in so we'll give them
a pass on going through a formal review).

-Toshio


pgpwZkb5_xTPH.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: python packages versus pydoc -k

[Toshio Kuratomi]

On Thu, Mar 13, 2014 at 09:11:12AM -0700, Josh Stone wrote:
> On 03/12/2014 06:12 PM, Toshio Kuratomi wrote:
> > On Wed, Mar 12, 2014 at 12:18:17PM -0700, Josh Stone wrote:

> >> Of course, these are just the first exceptions I hit.  Experience shows
> >> that fixing these will likely find more behind them.
> >>
> > Yeah, I think there's a never ending treadmill here.
> 
> Alright, I'll try not to let it bother me then.
>
Yeah... which is not to stop you from filing bugs and working on fixes if
you want... but I don't think we'll be able to maintain a working pydoc
-k... there's jsut too many ways it can go wrong whenever a python package
updates or is added.

-Toshio


pgpWmeCX6s4Sm.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: python packages versus pydoc -k

[Toshio Kuratomi]

On Wed, Mar 12, 2014 at 12:18:17PM -0700, Josh Stone wrote:
> Do we have any packaging requirements or guidelines for python modules
> to behave nicely with pydoc?  I've seen this break a number of times,
> and sometimes the bugs I've filed have been fixed, sometimes ignored.
> Before I go through another round, I'd like to know if we have (or
> should have) some official policy on this.
> 
We don't currently have any official guidelines on this.

I know that pydoc can be broken.  Because of how it works I'm not certain
that we can fix it and keep it fixed.

> AIUI, pydoc works by importing the named module, then displaying its
> docstrings.  Then "pydoc -k" does this for all modules in sys.path,
> looking for the specified keyword.  A problem then arises if something
> in the path does protect itself with 'if __name__ == "__main__":' to
> know when it's acting as a module or a script.  (And if some module
> really doesn't want to support normal importing, it should not be
> installed in the path!)
> 
There's also packages that need a non-default version of a dependency in
order to work.  We've worked out ways to do this so that the module can be
imported when we use them in an application but it will probably break with
the way pydoc -k works.

setuptools entrypoints can break unrelated code.  It's probably another way
that pydoc -k could be broken.

[..]
> 
> Of course, these are just the first exceptions I hit.  Experience shows
> that fixing these will likely find more behind them.
>
Yeah, I think there's a never ending treadmill here.


pgprsxW9r6Dwn.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: Per-Product Config file divergence

[Toshio Kuratomi]

On Mon, Mar 10, 2014 at 03:16:31PM -0400, Martin Langhoff wrote:
> On Mon, Mar 10, 2014 at 12:10 PM, Toshio Kuratomi  wrote:
> > The idea is to allow config file divergence via the alternatives system as
> 
> Will this handle user customization? IME alternatives is not geared to
> handle config files, customizable shell scripts, etc.
> 
That's an issue that I was trying to think through over the weekend.
I think you're right that alternatives by itself wouldn't handle this well.
I was trying to figure out if we could use alternatives to copy in a config
file instead of symlinking or check the hash of the file just like rpm would
do with any other config file but didn't get through my thought experiments.

It may be that vanilla alternatives is unsuitable but we want something
alternatives-like (an external tool that updates the config file) rather
than something based on rpm metadata (Conflicts which causes you to have
either one or the other package installed).

-Toshio


pgpZ8XQJw1fNS.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: Per-Product Config file divergence

[Toshio Kuratomi]

On Mar 10, 2014 11:09 AM, "Matthew Miller"  wrote:
>
> On Mon, Mar 10, 2014 at 10:09:43AM -0700, Toshio Kuratomi wrote:
> > > What will fedup updates of Fedora 20 look like? Would there be a flag,
> > > e.g. --product cloud/workstation/server? If not specified do we fail,
or
> > > is there a default?
> > The default should be whatever product was installed onto the system
> > originally.  Going from Fedora 20 to a Product in F21 is probably a
one-off
> > but I'm not sure what that should look like.  I could be totally wrong
but
> > I believe that each of the Products will have their own install image.
 With
> > that in mind, fedup might need a one-off bit of UI to ask which Product
> > image you want to use.  That image would then set the Product on the
disk
> > accordingly.
>
> I assume that we'll do something that makes it easy to read the existing
> product from the system -- I like fedora-release +
> fedora-release-{workstation,server,cloud} subpackages.
>
> And I think those subpackages probably _should_ conflict, don't you?
>

Depends.  Sgallagh had a desire to mark that a particular system
implemented multiple products (ie server that also had workstation
installed).  I'm not sure that's a good idea but if we did go that route
then we'd have to be able to support that with our identifiers.
Subpackages that conflict wouldn't be flexible enough to handle that.

-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

Re: Per-Product Config file divergence

[Toshio Kuratomi]

On Mon, Mar 10, 2014 at 12:08:40PM -0600, Kevin Fenzi wrote:
> On Mon, 10 Mar 2014 11:00:25 -0700
> Toshio Kuratomi  wrote:
> 
> > Perhaps spins should also specify a product identifier.  Maybe they
> > could have the ability to specify an existing products' identifier if
> > they are merely a variant set of packages top an existing product as
> > well.
> 
> But they aren't products... so that would be pretty confusing. 
> 
We don't necessarily have to limit the identifier to Official Products.  It's
purpose is to allow software to differentiate
this-thing-that-we-ship-that's-different-than-these-other-things.  So it
might be that spins fall into this category jsut as much as the Official
Products do.

> Yeah, if there was some spin built on top of workstation I assume they
> would just have the workstation product setup by pulling in the
> fedora-workstation-release and such. 

-Toshio


pgplUcG5cNk2I.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: Per-Product Config file divergence

[Toshio Kuratomi]

On Mar 10, 2014 10:22 AM, "Kevin Fenzi"  wrote:
>
> On Mon, 10 Mar 2014 10:09:43 -0700
> Toshio Kuratomi  wrote:
>
> > > What will fedup updates of Fedora 20 look like? Would there be a
> > > flag, e.g. --product cloud/workstation/server? If not specified do
> > > we fail, or is there a default?
> > >
> > > Or is this getting too far ahead of things?
> > >
> > The default should be whatever product was installed onto the system
> > originally.  Going from Fedora 20 to a Product in F21 is probably a
> > one-off but I'm not sure what that should look like.  I could be
> > totally wrong but I believe that each of the Products will have their
> > own install image.  With that in mind, fedup might need a one-off bit
> > of UI to ask which Product image you want to use.  That image would
> > then set the Product on the disk accordingly.
>
> Or we could simply say that fedup doesn't upgrade from a non product to
> a product. You have to re-install or use a manual method to do that
> (some yum/dnf commands, etc).
>
> We need to consider this case also for someone who installs Fedora, but
> not one of the products (a spin, or a custom kickstart or whatever) who
> then wants to install a product.
>
Perhaps spins should also specify a product identifier.  Maybe they could
have the ability to specify an existing products' identifier if they are
merely a variant set of packages top an existing product as well.

-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

Re: Per-Product Config file divergence

[Toshio Kuratomi]

On Mon, Mar 10, 2014 at 10:40:29AM -0600, Chris Murphy wrote:
> 
> On Mar 10, 2014, at 10:10 AM, Toshio Kuratomi  wrote:
> 
> > At last week's FESCo meeting, the fact that Products desired to have
> > divergent configuration was briefly touched on.  On Thursday, a few FPC
> > members had a brainstorming session about it and on Friday, sgallagh and
> > that brainstorming continued with sgallagh, adamw, tflink, notting, and
> > myself.  We came up with a tentative idea here:
> > 
> > https://fedoraproject.org/wiki/User:Toshio/Product_Divergence_(config)
> > 
> > The idea is to allow config file divergence via the alternatives system as
> > that already provides us with a commandline tool and some structure to build
> > on.  We'd still have to write a few pieces to complete the picture but it
> > seemed to be a better starting point than using rpm Conflicts between
> > config-packages.
> > 
> > Anyone have thoughts on this potential path?
> 
> What will fedup updates of Fedora 20 look like? Would there be a flag, e.g. 
> --product cloud/workstation/server? If not specified do we fail, or is there 
> a default?
> 
> Or is this getting too far ahead of things?
> 
The default should be whatever product was installed onto the system
originally.  Going from Fedora 20 to a Product in F21 is probably a one-off
but I'm not sure what that should look like.  I could be totally wrong but
I believe that each of the Products will have their own install image.  With
that in mind, fedup might need a one-off bit of UI to ask which Product
image you want to use.  That image would then set the Product on the disk
accordingly.

-Toshio


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

Per-Product Config file divergence

[Toshio Kuratomi]

At last week's FESCo meeting, the fact that Products desired to have
divergent configuration was briefly touched on.  On Thursday, a few FPC
members had a brainstorming session about it and on Friday, sgallagh and
that brainstorming continued with sgallagh, adamw, tflink, notting, and
myself.  We came up with a tentative idea here:

https://fedoraproject.org/wiki/User:Toshio/Product_Divergence_(config)

The idea is to allow config file divergence via the alternatives system as
that already provides us with a commandline tool and some structure to build
on.  We'd still have to write a few pieces to complete the picture but it
seemed to be a better starting point than using rpm Conflicts between
config-packages.

Anyone have thoughts on this potential path?

-Toshio


pgpp2bECF9uaP.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: [Guidelines Change] Changes to the Packaging Guidelines

[Toshio Kuratomi]

On Mar 9, 2014 7:49 AM, "Kevin Kofler"  wrote:
>
> Toshio Kuratomi wrote:
> > Directory and file interaction is a hard problem. There's no right thing
> > to do in this case.  The many possible things we could do all have one
> > drawback or another in certain cases.
>
> The right thing is clear: If all the files inside the directory are owned
by
> packages about to be removed in the transaction, just rm -rf the directory
> (or rather the equivalent in C code),

Yes, the simple case is simple.

> otherwise rename it with a suffix
> (.rpmsave, if necessary .rpmsave0, .rpmsave1, … , .rpmsave10, …) and only
> delete the files owned by packages about to be removed in the transaction.
>
But this is where the answers start to have drawbacks.  As just one
example, renaming the directory will break other packages which installed
files into that directory.

-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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Toshio Kuratomi]

On Mar 8, 2014 11:57 AM, "Kevin Kofler"  wrote:
>
> Tom Callaway wrote:
>
> > Changes to python-setuptools in F20 cause easy_install to install egg
> > files instead of egg directories by default. This sometimes causes
> > problems for rpms of multi-version python modules as the egg filenames
> > are the same if the version of the package hasn't been increased and rpm
> > is unable to replace the directory with a file. To fix this, the ​
> > https://fedoraproject.org/wiki/Packaging:Python_Eggs#Multiple_Versions
> > guideline has been updated to pass the "-Z" switch to easy_install which
> > restores the former behaviour of installing eggs as a directory.
> >
> > If you package a backwards or forwards compat python module that makes
> > use of the Multiple_Versions guideline (or easy_install in some other
> > way), please update your spec file to include the -Z switch.
>
> Couldn't we %pretrans-hack that?
>

In terms of possible, the answer is yes.  In terms of desirable, the answer
is no.  First, the hack you refer to is not guaranteed safe and should be
avoided when alternative meth odds exist.  This guideline change is such an
alternative that simply adds a single upstream cli flag to workaround the
problem.

Secondly, the current standard is to install most scripting language files
in human readable form.  The new easy_install default violates that. using
the flag restores that.

> And with all the issues this and the related symlink problem have caused,
> IMHO, it's really time to fix RPM to support these cases without hacks!

Directory and file interaction is a hard problem. There's no right thing to
do in this case.  The many possible things we could do all have one
drawback or another in certain cases.

-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

Re: [Guidelines Change] Changes to the Packaging Guidelines

[Toshio Kuratomi]

On Mar 8, 2014 11:57 AM, "Kevin Kofler"  wrote:
>
> Tom Callaway wrote:

> > The prohibition against packages installing files into /bin, /sbin,
> > /lib, and /lib4 has been removed and a section explaining how Fedora's
> > UsrMove? feature interacts with the rpm %files section has been added.
> > Packagers who maintain software that installs into /bin, /sbin, /lib,
> > and /lib64 historically or in upstream are encouraged to read that
> > section to understand what's best for their package: ​
> >
> >
https://fedoraproject.org/wiki/Packaging:Guidelines#Effect_of_the_UsrMove_Fedora_Feature
>
> Together with:
>
http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-provides-bin-file-does-not-find-any-packages-on-fedora
> doesn't that mean that users will have to run BOTH:
> dnf provides /usr/bin/foo
> AND
> dnf provides /bin/foo
> to check what package owns that particular file? That strikes me as
> extremely user-unfriendly.
>
I'm having trouble understanding what is being documented there.  It may be
something that should be "fixed" in dnf.  Fixed being a bit of a misnomer
because (1) it's more of a kludgy workaround that (2) can't work on all
situations.  But as you point out, sometimes ui can't be pure because the
things it's giving insight to are not very clean and neat themselves.

-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

Re: Meeting minutes for Env-and-Stacks WG meeting (2014-03-03)

[Toshio Kuratomi]

On Tue, Mar 04, 2014 at 03:23:28PM +0100, Marcela Mašláňová wrote:
> 
> * additional repository - Playground requirements  (mmaslano, 13:03:05)
>   * how do updates work (rolling? bodhi? Will we constantly be
> regenerating the repodata [like the rawhide build repo?])
> (mmaslano, 13:07:16)
>   * rolling + constantly regenerating repodata  (mmaslano, 13:10:26)
>   * one repo per Fedora release + arch  (tjanez, 13:11:14)
>   * daily push  (mmaslano, 13:12:25)
>   * no bodhi yet  (mmaslano, 13:14:02)
>   * Do we trust this person to keep the repo up to date and address
> serious bugs/security issues.  (mmaslano, 13:20:50)
>   * we could always have the fedora-playground-release package
> "Obsoletes: badapp-$version"  (mmaslano, 13:29:09)
>   * is there a testing repo?  (mmaslano, 13:42:12)
>   * testing repo - not needed, testing are coprs  (mmaslano, 13:43:07)
>   * The repo will attempt to do automatic package review, falling back
> to human intervention on known trouble cases such as Obsoletes.
> (tjanez, 14:02:13)
>   * ACTION: tjanez will add comments from our today's meeting to Open
> Questions  (mmaslano, 14:09:55)
> 
Did anyone forward the playground repo proposal on to FESCo?  FESCo needs to
know about things we are hooping to do in time for tomorrow's meeting
(officially, Monday, Mar 3... but discussion will start at the meeting
tomorrow).

-Toshio


pgp39Mqzgzb5W.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: System-wide crypto policy

[Toshio Kuratomi]

On Feb 27, 2014 8:25 AM, "Jaroslav Reznik"  wrote:
>
> = Proposed System Wide Change: System-wide crypto policy =
> https://fedoraproject.org/wiki/Changes/CryptoPolicy

> == Detailed Description ==
> The idea is to have some predefined security levels such as LEVEL-80,
> LEVEL-128, LEVEL-256,
> or ENISA-LEGACY, ENISA-FUTURE, SUITEB-128, SUITEB-256. These will be the
> security levels
> that the administrator of the system will be able to configure by
modifying
> /usr/lib/crypto-profiles/config
> /etc/crypto-profiles/config
>
> and being applied after executing update-crypto-profiles.
> (Note: it would be better to have a daemon that watches those files and
> runs update-crypto-profiles automatically)
>
> After that the administrator should be assured that any application
> that uses the system settings will follow a policy that adheres to
> the configured profile.
>
> Ideally setting a profile should be setting:
> * the acceptable TLS/SSL (and DTLS) versions
> * the acceptable ciphersuites and the preferred order
> * acceptable parameters in certificates and key exchange, i.e.:
> ** the minimum acceptable size of parameters (DH,ECDH,RSA,DSA,ECDSA)
> ** the acceptable elliptic curves (ECDH,ECDSA)
> ** the acceptable signature hash functions
> * other TLS options such as:
> ** safe renegotiation
>

Does this configuration limit the algorithms that are available or only the
options that can be given to those algorithms or only the default values of
those algorithms?

-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

Re: Packages with missing %check

[Toshio Kuratomi]

On Feb 26, 2014 5:16 AM, "Colin Walters"  wrote:
>
> On Wed, Feb 26, 2014 at 8:09 AM, Stanislav Ochotnicky <
sochotni...@redhat.com> wrote:
>>
>> "I" didn't name them. I used standard names for different testing levels
as defined by software engineering bodies. Quoting from SWEBOK:
>
>
> Yes, I think they're wrong.   Well, "suboptimal" is a better word.
>
>> During making glib changes you should run glib unit tests to have some
basic level of assurance you didn't introduce regressions or unwanted
changes.
>
>
> The *very first* test I run is "does the OS still boot"?  That's called
"smoketest" for me, and it only takes a few minutes.
>
> Yes, after every change, even just an updated translation, I boot the OS,
run through systemd, gdm, gnome-shelll, and everything and ensure it still
logs in.
>
> This is *before* I run the GTK+ tests or the glib tests or any other
test.  Why?  Because if that fails, there's *no point* to running the other
tests.  The system is broken.  The originating change is investigated and
is up for reverting.   Whether or not the GKeyFile test pass or not is
irrelevant.
>
> (Also, there is the fact that InstalledTests are guaranteed to be run in
a logged in desktop, not a mock chroot, so the above needs to work anyways)
>
>> It's great that your change helped with discovering issues but perhaps
your original testsuite was mixing different levels of testing in the same
code. Unit tests are supposed to be quick, dirty solutions using mock
objects and other "hacks" to allow of testing with small granularity.
>
>
> Ah, but if one makes "integration tests" very fast and easy to run as I
have, then there's less need for "quick and dirty".
>
Integration tests and unittests really have different purposes.
Integration tests test that things that you want to do aren't broken by a
change.  Unittests test that individual functional units aren't broken by a
change.

For a developer who can run their tests right after each commit there's
likely not a lot of difference.  For someone who's getting a code drop with
hundreds of commits in it, however, it's often easier to debug what's
causing a failing unittest than what's causing a failing integration test.
The reason is that ideally unittests isolate a small piece of code for
testing.  when it fails, the Unittest itself provides the clues to the
person debugging as to where the failure lies.

-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

Re: Packages with missing %check

[Toshio Kuratomi]

On Tue, Feb 25, 2014 at 12:45:11PM +0200, Alexander Todorov wrote:
> Hi guys,
> I have identified 551 packages on the Fedora 20 source DVD which are
> missing a %check section in their spec files but are very likely to
> have a test suite. See
> https://github.com/atodorov/fedora-scripts/blob/master/sample-data/fedora-20/srpms-with-tests-WITHOUT-check-in-fedora-20-dvd
> 
> For a few of them I already had bug open previously (will filter the
> list later when I run my scripts against latest Rawhide).
> 
> I have the following questions:
> 
> 1) Do we consider this a bug and if yes what priority do you give it?
> From last week discussions it looks like most people prefer to have
> tests executed in %check.
> 
https://fedoraproject.org/wiki/Packaging:Guidelines#Test_Suites

So in some set of cases this would be a bug.  I don't have an estimate of
how many test suites would be "practical to" execute the test suite though.

-Toshio


pgpuCMVJ_QYR9.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: Summary/Minutes from today's FESCo Meeting (2014-02-19)

[Toshio Kuratomi]

On Feb 24, 2014 1:46 AM, "Marcela Mašláňová"  wrote:
>
> On 02/19/2014 08:57 PM, Tomas Mraz wrote:
>>
>> * Open floor  (t8m, 19:45:44)
>>* AGREED: FESCo expects the Tech specs/docs from working groups by
>>  March 3rd at the latest (+7, -0, 0:0)  (t8m, 19:50:38)
>>* ACTION: t8m will update the weekly reports ticket with this request
>>  (t8m, 19:53:08)
>
>
> Env and Stacks WG are dependent on requirements from 3 products, so we
probably can't deliver on 3rd March.

We can start though.  For instance, we've decided that we're forging ahead
with the idea of a repo for less than perfect packages.  So we'll need the
support infrastructure for that.

- Disk space?
- hooked up to the mirror network?
- copr out of beta?
- what scripts and manpower does the new repo need?
- are we using bodhi, signing packages, etc?
- do we need a set of people who check what goes into the new repo?

-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

Re: python-django update to Django-1.6

[Toshio Kuratomi]

ocalflavor/??/*
-%{python_sitelib}/django/contrib/localflavor/??_??/*
-%dir %{python_sitelib}/django/contrib/localflavor/locale
-%dir %{python_sitelib}/django/contrib/localflavor/locale/??/
-%dir %{python_sitelib}/django/contrib/localflavor/locale/??_*/
-%dir %{python_sitelib}/django/contrib/localflavor/locale/*/LC_MESSAGES/
-%dir %{python_sitelib}/django/contrib/markup/
-%dir %{python_sitelib}/django/contrib/messages/
-%dir %{python_sitelib}/django/contrib/messages/locale
-%dir %{python_sitelib}/django/contrib/messages/locale/??/
-%dir %{python_sitelib}/django/contrib/messages/locale/??_*/
-%dir %{python_sitelib}/django/contrib/messages/locale/*/LC_MESSAGES
-%dir %{python_sitelib}/django/contrib/redirects
-%dir %{python_sitelib}/django/contrib/redirects/locale
-%dir %{python_sitelib}/django/contrib/redirects/locale/??/
-%dir %{python_sitelib}/django/contrib/redirects/locale/??_*/
-%dir %{python_sitelib}/django/contrib/redirects/locale/*/LC_MESSAGES
-%dir %{python_sitelib}/django/contrib/sessions/
-%dir %{python_sitelib}/django/contrib/sessions/locale/
-%dir %{python_sitelib}/django/contrib/sessions/locale/??/
-%dir %{python_sitelib}/django/contrib/sessions/locale/??_*/
-%dir %{python_sitelib}/django/contrib/sessions/locale/*/LC_MESSAGES
-%dir %{python_sitelib}/django/contrib/sitemaps/
-%dir %{python_sitelib}/django/contrib/sites/
-%dir %{python_sitelib}/django/contrib/sites/locale/
-%dir %{python_sitelib}/django/contrib/sites/locale/??/
-%dir %{python_sitelib}/django/contrib/sites/locale/??_*/
-%dir %{python_sitelib}/django/contrib/sites/locale/*/LC_MESSAGES
-%dir %{python_sitelib}/django/contrib/staticfiles/
-%dir %{python_sitelib}/django/contrib/syndication/
-%dir %{python_sitelib}/django/contrib/webdesign/
-%{python_sitelib}/django/contrib/*/*.py*
-%{python_sitelib}/django/contrib/*/fixtures/
-%{python_sitelib}/django/contrib/*/handlers/
-%{python_sitelib}/django/contrib/*/management/
-%{python_sitelib}/django/contrib/*/plugins/
-%{python_sitelib}/django/contrib/*/templates/
-%{python_sitelib}/django/contrib/*/templatetags/
-%{python_sitelib}/django/contrib/*/tests/
-%{python_sitelib}/django/contrib/*/views/
-%{python_sitelib}/django/contrib/gis/admin/
-%{python_sitelib}/django/contrib/gis/db/
-%{python_sitelib}/django/contrib/gis/forms/
-%{python_sitelib}/django/contrib/gis/gdal/
-%{python_sitelib}/django/contrib/gis/geometry/
-%{python_sitelib}/django/contrib/gis/geos/
-%{python_sitelib}/django/contrib/gis/maps/
-%{python_sitelib}/django/contrib/gis/sitemaps/
-%{python_sitelib}/django/contrib/gis/utils/
-%{python_sitelib}/django/contrib/localflavor/generic/
-%{python_sitelib}/django/contrib/localflavor/in_/
-%{python_sitelib}/django/contrib/localflavor/is_/
-%{python_sitelib}/django/contrib/messages/storage/
-%{python_sitelib}/django/contrib/sessions/backends/
-%{python_sitelib}/django/forms/
-%{python_sitelib}/django/templatetags/ 
-%{python_sitelib}/django/core/
-%{python_sitelib}/django/http/
-%{python_sitelib}/django/middleware/
-%{python_sitelib}/django/test/
-%{python_sitelib}/django/conf/*.py*
-%{python_sitelib}/django/conf/project_template/
-%{python_sitelib}/django/conf/app_template/
-%{python_sitelib}/django/conf/urls/
-%{python_sitelib}/django/conf/locale/*/*.py*
-%{python_sitelib}/django/conf/locale/*.py*
-
-%{python_sitelib}/*.egg-info
-
- 
+
+%{python_sitelib}/*.egg
 
 %files doc
 %defattr(-,root,root,-)
@@ -301,6 +165,9 @@ cd tests
 
 
 %changelog
+* Fri Feb 21 2014 Toshio Kuratomi  - 1.4.8-1.1
+- Initial test of parallel installable version
+
 * Mon Sep 16 2013 Matthias Runge  - 1.4.8-1
 - update to 1.4.8, fix CVE-2013-1443 (DoS via large passwords)
 - fixes rhbz#1008282
Index: Django-1.4.8/setup.py
===
--- Django-1.4.8.orig/setup.py
+++ Django-1.4.8/setup.py
@@ -1,4 +1,4 @@
-from distutils.core import setup
+from setuptools import setup
 from distutils.command.install_data import install_data
 from distutils.command.install import INSTALL_SCHEMES
 import os


pgpwMy5O4o9w2.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: rpm bug 1065563 affecting httpd / php packages

[Toshio Kuratomi]

On Mon, Feb 17, 2014 at 10:56:14AM +, Joe Orton wrote:
> On Mon, Feb 17, 2014 at 12:37:53PM +0200, Ville Skyttä wrote:
> > I don't think this calls for a mass rebuild or any kind of a rebuild
> > actually, nor should it be rawhide only. AFAIU this doesn't affect
> > runtime at all, only build time, and affected packages can be just
> > fixed at the same time if they need an update in affected releases in
> > the first place.
> 
> The new rpmbuild cannot build an httpd which will satisfy dependencies 
> of current Fedora packages.  The new rpmbuild will force us to break the 
> existing ABI dependency for httpd, breaking compatibility with existing 
> and third-party packages.  And all that breakage is for zero gain, with 
> a bunch of engineering time wasted.
> 
> This change is inappropriate for a F19/20 update IMO.  Yes, we know the 
> deps are "wrong", but that was not hurting any Fedora users, and we've 
> fixed it properly for F21.
> 
I think this depends on what rpm and yum are currently doing with the
dependencies.  As Panu says here:
https://bugzilla.redhat.com/show_bug.cgi?id=1065563#c1 if "-" is used in
version or release then rpm and yum have to guess about what portion of hte
string is the version and which is the release.

If rpm/yum are doing the wrong thing in a large number of cases (there's
several ways it could be "wrong" -- one portion of the stack is parsing it
as Version: 20140215-x86 Release: 64 and another is parsing it as Version:
20140215 Release: x86-64;  there's a manual version comparison somewhere
that's looking for something like httpd-mmn >= 20140215 which always
evaluates false because the Provides is evaluating to Version: 20140215-x86;
etc) then it can be effectively argued that the provides themselves need to
be fixed in the stable Fedora release.  rpmbuild's refusal to build is
simply a helpful tool for showing where these broken Provides are present.

However, it could also be that over the course of time rpm and the software
built on top of it has evolved to make the same guess about where to separate
version-release in the ambiguous case.  If that's the case then sure, rpm
could continue to allow the broken behaviour in stable releases and only
make the change in rawhide.

I'd leave it to Panu and the rpm team to let us know which of those
scenarios are true for the current code.

-Toshio


pgpjADYu0Jmk_.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: Heads-up: updating python-sphinx to 1.2.1 in Rawhide

[Toshio Kuratomi]

On Wed, Feb 12, 2014 at 10:54:14AM -0500, Stephen Gallagher wrote:
>  Quite a lot of packages rely on Sphinx, so I
> think we may even want to deal with this in a side-tag.
>
>
My understanding from Dennis is that creating and then merging side tags in
koji is not a trivial thing (I can't remember is it's labor intensive when
merging back or whether having a lot of side-tags is bad for koji's
performance.)

Since sphinx is used very little at runtime and since there's not a deep
circular dep chain (sphinx requires docutils.  docutils does not require
sphinx [although, looking at the source, it could be changed to rebuild its
docs using sphinx at buildtime]) this seems like it might be better to deal
with fallout in rawhide than go through the creation of a side tag.

Pre-view packages in copr (or a scratch build link) does sound like a nice
thing, though (although my reading of the incompatibilities is that most
packages won't hit those issues.)

-Toshio


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

Summary/Minutes for today's FESCo Meeting (2014-02-12)

[Toshio Kuratomi]

===
#fedora-meeting: FESCO (2014-02-12)
===


Meeting started by abadger1999 at 18:01:58 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting/2014-02-12/fesco.2014-02-12-18.01.log.html
.



Meeting summary
---
* init process  (abadger1999, 18:02:02)

* New FESCo  (abadger1999, 18:04:01)
  * LINK:

https://lists.fedoraproject.org/pipermail/devel-announce/2014-February/001300.html
(abadger1999, 18:04:06)
  * Thanks to mmaslano for her service and welcome to dgilmore
(sgallagh, 18:06:06)
  * LINK:
https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee
https://fedoraproject.org/wiki/Extras/SteeringCommitteeHistory
(abadger1999, 18:06:06)
  * ACTION: nirik to take care of the mailing list switch  (abadger1999,
18:06:20)
  * ACTION: abadger1999 to take care of updating trac and the 2 fesco
wiki pages  (abadger1999, 18:07:54)

* #1221 (Product working group activity reports) – FESCo  (abadger1999,
  18:08:19)
  * very little WG activity as a lot of people were running around to
conferences  (mattdm, 18:09:25)
  * fesco acks the notes on WG progress  (abadger1999, 18:13:29)

* #1178 (Fedora 21 scheduling strategy) – FESCo  (abadger1999, 18:13:40)
  * FESCo needs the list of necessary changes from existing Fedora
procedures needed to release the products.  (abadger1999, 18:14:25)
  * ACTION: mattdm to help coordinate the engagement of talking with
other teams once we get the list of changes.  (abadger1999,
18:15:09)
  * ACTION: sgallagh to send message to devel-announe that talks about
where to discuss the initial list of changes to existing Fedora
procedures  (abadger1999, 18:20:01)
  * ACTION: sgallagh to send what we need next from WGs message to
liasons to bring to the next WG meeting  (abadger1999, 18:21:51)

* #1198 (Possible changes to Fedora EOL bug procedure) – FESCo
  (abadger1999, 18:26:27)
  * ACTION: mattdm to check if it's possible to do the
anyone-can-repoen-closed-eol  (mattdm, 18:42:08)

* #1197 (Procedure for suggesting/approving different Products and/or
  WGs?) – FESCo  (abadger1999, 18:44:44)
  * Continue to discuss how to make new products on mailing list
(abadger1999, 19:09:15)

* #1231 (Provenpackager request: averi) – FESCo  (abadger1999, 19:09:24)
  * averi approved as a provenpackager (+1:7, 0:1, -1:0)  (abadger1999,
19:13:31)

* #1229 (RFC: add WG liasons to FESCo mailing list?) – FESCo
  (abadger1999, 19:13:41)
  * Adding liasons to fesco list passed (+1:7, 0:1, -1:0)  (abadger1999,
19:19:30)

* #1230 (Requesting FESCo address Cherokee logo issue) – FESCo
  (abadger1999, 19:19:50)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1060984   (nirik,
19:30:08)
  * LINK: https://fedorahosted.org/fesco/ticket/1230#comment:10
(abadger1999, 19:31:18)
  * LINK:

https://github.com/cherokee/webserver/commit/965311bf0ff0f00556abfbc425fe2dc9c52f5533
(nirik, 19:33:30)
  * package maintainer to remove or replace the offensive logo(s). If
maintainer refuses or 2 weeks pass, package to be retired from
fedora and no longer shipped PASSED (+1:8, 0:0, -1:0)  (abadger1999,
19:38:54)
  * fesco notes that the upstream "censored logo" is also deemed to fall
into the offensive category.  (abadger1999, 19:39:46)

* #1233 (Nonresponsive maintainer: steve) – FESCo  (abadger1999,
  19:39:57)
  * decide whether to orphan other packages owned by steve next week
since it's not clear if the week since direct email was sent has
expired.  (abadger1999, 19:46:25)
  * defered to next week  (abadger1999, 19:52:37)

* #1179 (Interactions of the various Products) – FESCo  (abadger1999,
  19:52:59)

* Next week's chair  (abadger1999, 19:54:51)
  * t8m to chair next week's meeting  (abadger1999, 19:55:27)

* Open Floor  (abadger1999, 19:55:31)
  * we'll continue with current time for now (dgilmore is the one most
inconvenienced, may have to adapt later)  (abadger1999, 19:57:43)

Meeting ended at 20:01:17 UTC.




Action Items

* nirik to take care of the mailing list switch
* abadger1999 to take care of updating trac and the 2 fesco wiki pages
* mattdm to help coordinate the engagement of talking with other teams
  once we get the list of changes.
* sgallagh to send message to devel-announe that talks about where to
  discuss the initial list of changes to existing Fedora procedures
* sgallagh to send what we need next from WGs message to liasons to
  bring to the next WG meeting
* mattdm to check if it's possible to do the
  anyone-can-repoen-closed-eol




Action Items, by person
---
* abadger1999
  * abadger1999 to take care of updating trac and the 2 fesco wiki pages
* mattdm
  * mattdm to help coordinate the engagement of talking with other teams
once we get the list of changes.
  * mattdm to check if it's possible to do the
  

Schedule for Wednesday's FESCo Meeting (2014-02-12)

[Toshio Kuratomi]

Long agenda this week due to not having a meeting last week.  I've tried to
put the easiest things first (other than #1197 which is a followup item) to
try to clear out as many as possible.


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 '2014-02-12 18:00 UTC'


Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

#topic New FESCo
https://lists.fedoraproject.org/pipermail/devel-announce/2014-February/001300.html

#topic #1221 (Product working group activity reports) – FESCo
.fesco 1221
https://fedorahosted.org/fesco/ticket/1221

#topic #1198 (Possible changes to Fedora EOL bug procedure) – FESCo
.fesco 1198
https://fedorahosted.org/fesco/ticket/1198#comment:58

#topic #1197 (Procedure for suggesting/approving different Products and/or 
WGs?) – FESCo
.fesco 1197
https://fedorahosted.org/fesco/ticket/1197


= New business =

#topic #1231 (Provenpackager request: averi) – FESCo
.fesco 1231
https://fedorahosted.org/fesco/ticket/1231

#topic #1229 (RFC: add WG liasons to FESCo mailing list?) – FESCo
.fesco 1229
https://fedorahosted.org/fesco/ticket/1229

#topic #1230 (Requesting FESCo address Cherokee logo issue) – FESCo 
.fesco 1230
https://fedorahosted.org/fesco/ticket/1230

#topic #1233 (Nonresponsive maintainer: steve) – FESCo
.fesco 1233
https://fedorahosted.org/fesco/ticket/1233

#topic #1178 (Fedora 21 scheduling strategy) – FESCo
.fesco 1178
https://fedorahosted.org/fesco/ticket/1178

#topic #1179 (Interactions of the various Products) – FESCo
.fesco 1179
https://fedorahosted.org/fesco/ticket/1179

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

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/fesco,
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. 


pgpYyFrEcWNYn.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: What is bundling?

[Toshio Kuratomi]

On Mon, Feb 10, 2014 at 11:54:47AM +0100, Florian Weimer wrote:
> What is bundling in the sense of
> ?
> 
> In my opinion, the page deals with source package contents.
> 
> But there are other things a package can do "bundle" things in the
> binary packages, by copying code and data from installed packages in
> the build root.  These have comparable negative effects to bundling
> at the source package level.  Examples are static linking (already
> covered elsewhere), Java "static" linking (jarjar, Maven bundling,
> perhaps others), things like minify/lstrip/fatpack, copying programs
> and .so files out of the build root, etc.
> 
> Are these post-SRPM copying mechanism in scope for the "no bundled
> libraries" page, or should they be covered in other places?

These strategies usually come to the FPC in the context of bundled libraries
but they're actually static linking examples.  In general, the FPC considers
bundled libraries to be very problematic, static linking (and their analogs,
like packaging a library's source and then having a dependent package
compile against that) to be somewhat problematic, and shared libraries to be
preferred.

When there is "no reason" (the FPC is often called upon to evaluate whether
a valid reason exists) not to take the preferred strategy, packages need to
be modified to take that route.  If the FPC finds a valid reason for that
not to work, then the static linking alternatives are looked at and finally
the bundling alternatives.

-Toshio


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

Orphaned packages

[Toshio Kuratomi]

We no longer have valid contact information for the following packagers due
to changes in their work duties:

* npajkovs
* fkocina
* zpavlas

For packages that they own we have orphaned the packages and made them
comaintainers.  In the future, if their current fas email addresses start to
bounce, we will need to remove the accounts from the pkgdb altogether.  If
anyone knows of a way to contact them to ask if they would still like to
maintain any of their packages we would appreciate it.  They'd need to
update their email address in fas and retake ownership of packages that were
orphaned as part of this.

The following packages have been orphaned.  Feel free to take them over if
you care about them:

npajkovs:
* inn (f19-devel and epel7)
* iptraf-ng (f19-devel epel5-6)
* irssi-xmpp (f19-devel)

fkocina:
* librtas (f19-devel)
* libservicelog (f19-devel)
* netatalk (f19-devel epel5-6)
* powerpc-utils-python (f19-devel)
* servicelog (f19-devel)

-Toshio


pgpWuMr1K_5Wr.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: GIT development branches for packagers?

[Toshio Kuratomi]

On Jan 16, 2014 10:19 AM, "Andrew Lutomirski"  wrote:
>
> On Thu, Jan 16, 2014 at 10:15 AM, Adam Williamson 
wrote:
> > On Wed, 2014-01-15 at 11:29 +0100, Tomas Mraz wrote:
> >> On Út, 2014-01-14 at 13:13 -0800, Andrew Lutomirski wrote:
> >> > On Tue, Jan 14, 2014 at 12:59 PM, Adam Williamson <
awill...@redhat.com> wrote:
> >> > > On Tue, 2014-01-14 at 12:41 -0800, Andrew Lutomirski wrote:
> >> > >> I have some trivial cleanups I want to make to a package a
maintain.
> >> > >> These cleanups are trivial enough that I don't think they're
worth a
> >> > >> new build.  Should I commit them to the master branch?  If so, I
can
> >> > >> imagine a couple of issues:
> >> > >>
> >> > >>  - A provenpackager could kick off a rebuild for whatever reason
(e.g.
> >> > >> dependency soname bump).  That will (I think) inadvertently
include my
> >> > >> changes.
> >> > >
> >> > > Yes, this will happen. Why do you think it's a problem, though? If
your
> >> > > changes are correct but you just don't think it's worth doing a new
> >> > > build simply for them, why is it a problem if they get pulled in
when
> >> > > someone does another build for some *other* (presumably
appropriate)
> >> > > reason? It would seem like that's just what you'd want to happen.
> >> >
> >> > Depends how well I've tested.  I'd like to imagine that I never
commit
> >> > anything broken anywhere, but this is empirically incorrect -- I
break
> >> > development branches on a semi-regular basis.  I guess I'll just have
> >> > to be more cautious w/ Fedora :)
> >> >
> >> > >
> >> > >>  - I need to think about whether to add a changelog entry or not.
 If
> >> > >> not, those changes might be included silently.  If yes, then I
need to
> >> > >> think about what to do about the revision number.
> >> > >
> >> > > One thing I've seen done is to add the line that actually
describes the
> >> > > change, above the last date/builder/NEVR line, *without* adding a
new
> >> > > line identifying the new build, date and builder. That way when
someone
> >> > > comes along and does a new build, they ought to see what should
happen -
> >> > > they should roll your partial entry into the entry they add for the
> >> > > build.
> >> >
> >> > That would work.
> >>
> >> I'd recommend rather the approach suggested by Kevin. Bump the release
> >> and include a regular changelog entry. Just do not build. There is no
> >> rule that all changeloged entries must be really built.
> >
> > I have found this kind of phantom release a bit annoying in some really
> > esoteric situations - when the changelog indicates that there was, say,
> > a 1.2-6 build, but there never was, only 1.2-5 and 1.2-7 - but most of
> > the time it's not going to be a problem, yeah.
>
> I can imagine this annoying anyone who does a mass rebuilt or a
> similar set of rebuilds that aren't intended (by the one doing the
> rebuilds) to change anything other than dependencies and, say, the
> compiler version.  Sure, this *shouldn't* cause a problem if everyone
> is appropriately careful, but I'm hesitant to trust things that
> transparently deploy code when no has has explicitly asked for a
> change to be deployed.
>

Yeah, I wouldn't trust my un built changes either :-).  But I think I'd go
with another of Kevin's options - go ahead and build in rawhide.  There's
really no downside to getting your this type of change out there sooner
rather than later.

-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

Re: dnf versus yum

[Toshio Kuratomi]

On Jan 9, 2014 6:26 AM, "Chris Adams"  wrote:
>
> Once upon a time, Toshio Kuratomi  said:
> >   Just have yum drop a config file in there that protects the
kernel
> > rather than protecting the kernel if some other package chooses to
protect
> > something else.
>
> The magic "don't delete the running kernel" can't be done with just a
> config file.  Something has to detect which kernel version is running
> and match it to an RPM, and then protect just that version of multiple
> installed kernel RPMs.
>

Can't the meaning of a package name in the config file simply mean: "make
sure one of these packages is always installed"?

That won't protect the running kernel but it will protect a kernel
(probably the latest installed).  That would seem to address hreindl's use
case of wanting to test on multiple systems and when satisfied that things
are working cleanup all older packages.

That would still be a difference from the current yum code but less than
not having any protection at all and would be more generic.

-Toshio

> I supposed you could do it external to yum/dnf with a boot-time script
> that rewrites a config file to protect kernel-$(uname -r), but that may
> not always work (it would have to handle things like kernel-PAE and
> such).
>
> --
> Chris Adams 
> --
> 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: dnf versus yum

[Toshio Kuratomi]

On Jan 7, 2014 4:53 AM, "Frank Murphy"  wrote:
>
> On Thu, 02 Jan 2014 16:28:59 +0100
> Reindl Harald  wrote:
>
> > look like it starts to happen again: a replacement which is not ready
> >
> https://bugzilla.redhat.com/show_bug.cgi?id=1049310
>
> It seems the majority want the current dnf default [1] to be kept
> Those who want to keep "running" kernel may need to speak up [2]
>
> [1]
>
http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-packages-called-kernel
>
> [2]
> https://bugzilla.redhat.com/show_bug.cgi?id=1049310

After asking on the bugzilla it seems that ales would like people who want
this change to cc themselves on the bug report.  If the cc reaches 40 he'll
reconsider.  Kinda a strange way of deciding but whatever works for the
maintainer I guess.

-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

Re: dnf versus yum

[Toshio Kuratomi]

On Wed, Jan 08, 2014 at 02:56:14PM -0500, Bill Nottingham wrote:
> Matthew Miller (mat...@fedoraproject.org) said: 
> > I'm a little lost in the thread, but do you mean that yum's protected
> > packages functionality is undocumented? If that is what you mean, check the
> > man page. It says:
> > 
> >   protected_packages  This  is  a list of packages that yum should
> >   never completely remove. They are  protected  via  Obsoletes  as
> >   well as user/plugin removals.
> > 
> >   The  default  is:  yum  glob:/etc/yum/protected.d/*.conf  So any
> >   packages which should be protected can do so by including a file
> >   in /etc/yum/protected.d with their package name in it.
> > 
> >   Also  if  this  configuration  is set to anything, then yum will
> >   protect the package corresponding to the running version of  the
> >   kernel.
> 
> While documented, I do find this last bit of behavior extremely odd and
> non-intuitive. (And hardcoded, no less.)
> 
  Just have yum drop a config file in there that protects the kernel
rather than protecting the kernel if some other package chooses to protect
something else.

-Toshio


pgpS06jtjRQjT.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 - 2014-01-05

[Toshio Kuratomi]

On Tue, Jan 07, 2014 at 09:25:36AM +0100, Simone Caronni wrote:
> On 6 January 2014 20:53, Kevin Fenzi  wrote:
> 
> slaanesh:BADSOURCE:dkms-2.2.0.3.tar.gz:dkms
> 
> 
> Downloading the file again gives a different md5sum, but the release tarball 
> is
> the same, so probably the archive has been regenerated.
> 
> What's the procedure to update the source files in the lookaside cache when 
> the
> file name has not changed? fedpkg new-sources does not allow me to do it:
> 
This should work.

> $ fedpkg new-sources dkms-2.2.0.3.tar.gz
> Uploading: 11a8aaade2ebec2803653837c7593030  dkms-2.2.0.3.tar.gz
> File already uploaded: dkms-2.2.0.3.tar.gz
> Uploaded and added to .gitignore:
> Source upload succeeded. Don't forget to commit the sources file
> 
Looking at the lookaside cache directly, it looks like that file has been
uploaded previously (in lookaside, there's currently two tarballs for
dkms-2.2.0.3.tar.gz with two separate md5sums).  Has the upstream perhaps
released a tarball, released a new tarball, and then reverted to the
original one?

One option is to change the sources file to reflect the new md5sum.

You may also want to check that the new tarball and the tarball in the
lookaside cache *really* are the same.  A hash collision is unlikely but if
that were the case we'd want to be extra certain about what's going on
before blindly accepting the changed tarball.

You can retrieve the tarballs in lookaside directly from here:
http://pkgs.fedoraproject.org/lookaside/pkgs/dkms/dkms-2.2.0.3.tar.gz/

-Toshio


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

python compat package change needed

[Toshio Kuratomi]

The new setuptools shipped in F20+ has one change that breaks things for
a subset of python packages.  I'm proposing a very small guideline change
for the Pyhton Eggs guidelines to address that.  Maintainers of backwards
and forward compat packages will likely want to address this as it will
break upgrades of those backwards compat packages from f19 to f20.

When we ship backwards compat pyhton modules we take advantage of a feature
of pythhon eggs to install the multiple versions:
https://fedoraproject.org/wiki/Packaging:Python_Eggs#Multiple_Versions

The guidelines say to use the following command line for performing the
install:

   easy_install -m --prefix $RPM_BUILD_ROOT%{_usr} dist/*.egg

In Fedora 19's setuptools package, this resulted in a new directory being
installed into site-packages that held the versioned egg.

In Fedora 20's setuptools package, this command results in a zipped egg file
being installed into site-packages.  The zipped egg has the same filename as
the previous directory.

This causes problems for rpm as rpm cannot handle replacing a directory with
a file without jumping through hoops.  Because rpm cannot perform that
replacement, we end up with bug reports like this:
  https://bugzilla.redhat.com/show_bug.cgi?id=1047570#c0
where the user is unable to upgrade the F19 package to the F20 package.

The solution is to force easy_install to install unzipped eggs rather than
zipped eggs.  This can be done via a command line switch, -Z.  I've proposed
adding that switch to the Pyhton Eggs guidelines:

https://fedorahosted.org/fpc/ticket/378

If you get similar bug reports to the one menitoned, you can add the switch
to workaround the problem now.  I'll send a new message to this list if (for
some reason I don't know about) adding -Z is deemed unacceptable.

-Toshio


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

Re: Source file audit - 2014-01-05

[Toshio Kuratomi]

On Mon, Jan 06, 2014 at 12:53:04PM -0700, Kevin Fenzi wrote:
> - 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-20140105/$packagename-dl.txt
> 
Correction:

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

-Toshio


pgpiLqaMy5npZ.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: setuptools status on Fedora 20

[Toshio Kuratomi]

On Thu, Dec 19, 2013 at 09:42:11PM +0530, Kushal Das wrote:
> # setup
> 
> ERROR - No tool descriptions found in /etc/setuptool.d or
> /usr/share/setuptool/setuptool.d.
> 
Kushal and I did some debugging on this this morning and determined that
it's the error message being a bit inaccurate.  The tool descriptions are
being found but on this particular box, none of the tool's that the
descriptions reference were installed.  The error message should say that
none of the tools were findable rather than none of the tool descriptions.

By installing one of the backend tools, things worked as expected.

-Toshio


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

Summary/Minutes from today's FESCo Meeting (2013-12-18)

[Toshio Kuratomi]

===
#fedora-meeting: FESCO (2013-12-18)
===


Meeting started by abadger1999 at 18:02:28 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting/2013-12-18/fesco.2013-12-18-18.02.log.html
.



Meeting summary
---
* init process  (abadger1999, 18:02:33)

* 1198 Possible changes to Fedora EOL bug procedure  (abadger1999,
  18:05:59)
  * send warning now, gather more info and revisit before sending
close/closing. Passed (+1: 6, 0:0, -1:0)  (abadger1999, 18:17:29)
  * ACTION: mattdm to verify that reopening works before it's time to
close the EOL bugs.  (abadger1999, 18:17:51)

* #1209 please allow the assignee to remove private status
  (abadger1999, 18:18:08)
  * ask bugzilla.redhat.com maintainers to allow assignees on private
abrt bugs to unmark them private if they choose (implementation
could be tied to assignee or a new privledge for fedorabugs)  Passed
(+1:6, 0:0, -1:0)  (abadger1999, 18:23:19)
  * ACTION: nirik to open the bug to have bugzilla maintainers look at
adding this permission  (abadger1999, 18:25:51)

* #1132 libtool + %global _hardened_build 1 = no full hardening
  (abadger1999, 18:26:12)
  * ACTION: t8m will ask praiskup about the new %configure hack  (t8m,
18:35:12)
  * LINK:
https://bugzilla.redhat.com/attachment.cgi?id=782186&action=diff
(abadger1999, 18:35:45)
  * Defer the libtool question until next meeting so we can get more
information (+1:6, 0:0, -1:0)  (abadger1999, 18:41:21)

* #956Need to audit packageset for bundling of libiberty
  (abadger1999, 18:41:31)
  * ACTION: abadger199 to modify the proposal to include what's in the
bugzilla comment 30 and link to the upstream patch for the Analysis
section and move analysis to the second option.  (abadger1999,
18:59:13)
  * With the modifications that abadger1999 will make, the poroposal is
approved (+1:5, 0:0, -1:0)  (abadger1999, 18:59:49)
  * ACTION: abadger1999 to take care of the bug filings and other
followup as well  (abadger1999, 19:00:19)

* Next week's chair  (abadger1999, 19:00:42)
  * Next meeting Wed, January 8th.  t8m to chair  (abadger1999,
19:01:30)

* Open Floor  (abadger1999, 19:01:34)
  * A round of applause for everyone who worked on fedora 20
(abadger1999, 19:02:23)

* #1212 (Unresponsive package maintainer policy change proposal) – FESCo
  - https://fedorahosted.org/fesco/ticket/1212  (abadger1999, 19:18:56)
  * Reject this for now, until there are signs that his one example is
becoming a common problem, and ask him to come back asking for
remedy for his specific problem on an individual basis. (+1:6, 0:0,
-1:0)  (abadger1999, 19:19:18)

* Open Floor  (abadger1999, 19:19:28)

Meeting ended at 19:20:51 UTC.




Action Items

* mattdm to verify that reopening works before it's time to close the
  EOL bugs.
* nirik to open the bug to have bugzilla maintainers look at adding this
  permission
* t8m will ask praiskup about the new %configure hack
* abadger199 to modify the proposal to include what's in the bugzilla
  comment 30 and link to the upstream patch for the Analysis section and
  move analysis to the second option.
* abadger1999 to take care of the bug filings and other followup as well




Action Items, by person
---
* abadger1999
  * abadger1999 to take care of the bug filings and other followup as
well
* mattdm
  * mattdm to verify that reopening works before it's time to close the
EOL bugs.
* nirik
  * nirik to open the bug to have bugzilla maintainers look at adding
this permission
* t8m
  * t8m will ask praiskup about the new %configure hack
* **UNASSIGNED**
  * abadger199 to modify the proposal to include what's in the bugzilla
comment 30 and link to the upstream patch for the Analysis section
and move analysis to the second option.




People Present (lines said)
---
* abadger1999 (104)
* nirik (53)
* t8m (28)
* pjones (22)
* sgallagh (16)
* notting (16)
* jreznik (15)
* mattdm (14)
* zodbot (11)
* jwb (3)
* 77CAAU64F (2)
* mmaslano (0)
* mitr (0)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-- 
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: setuptools status on Fedora 20

[Toshio Kuratomi]

On Thu, Dec 19, 2013 at 07:43:40AM -0500, Jared K. Smith wrote:
> On Thu, Dec 19, 2013 at 3:08 AM, Kushal Das  wrote:
> 
> ERROR - No tool descriptions found in /etc/setuptool.d or
> /usr/share/setuptool/setuptool.d.
> 
> Are we going to deprecate the package ?
> 
> 
> Not that I'm aware of -- I wonder if you're hitting some sort of side effect 
> of
> https://fedoraproject.org/wiki/Changes/Remove_Python-setuptools-devel
> 
The setuptool and python-setuptools package shouldn't affect each other.

Are there files inside of /etc/setuptool.d ?  Does rpm -V setuptool tell you
any files are missing?

$ rpm -qpl setuptool-1.19.11-7.fc20.x86_64.rpm  |grep setuptool.d
/etc/setuptool.d
/etc/setuptool.d/98netconfig
/etc/setuptool.d/98system-config-authentication
/etc/setuptool.d/98system-config-display
/etc/setuptool.d/98system-config-keyboard
/etc/setuptool.d/99Xconfigurator
/etc/setuptool.d/99authconfig
/etc/setuptool.d/99kbdconfig
/etc/setuptool.d/99mouseconfig
/etc/setuptool.d/99ntsysv
/etc/setuptool.d/99printconf-tui
/etc/setuptool.d/99sndconfig
/etc/setuptool.d/99system-config-firewall-tui
/etc/setuptool.d/99system-config-network-tui
/etc/setuptool.d/99timeconfig
/usr/share/setuptool/setuptool.d


-Toshio


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

Schedule for Wednesday's FESCo Meeting (2013-12-18)

[Toshio Kuratomi]

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 '2013-12-18 18:00 UTC'


Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

#1209   please allow the assignee to remove private status
.fesco 1209 
https://fedorahosted.org/fesco/ticket/1209

#1212   Unresponsive package maintainer policy change proposal
.fesco 1212
https://fedorahosted.org/fesco/ticket/1212

#1132   libtool + %global _hardened_build 1 = no full hardening
.fesco 1132
https://fedorahosted.org/fesco/ticket/1132

#956Need to audit packageset for bundling of libiberty
.fesco 956
https://fedorahosted.org/fesco/ticket/956


= New business =


= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

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/fesco,
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. 


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

Shared System Certificates followup: Packaging Guidelines?

[Toshio Kuratomi]

Last night someone asked me about a package that they were working on that
had a pem file in it.  Looking closer, it seems that the pem file is
a cacert bundle.  Looking around, there's not currently documentation on
what to do with these.  I did find some information on the wiki, though:

  https://fedoraproject.org/wiki/PackagingDrafts/Certificates
  https://fedoraproject.org/wiki/Features/SharedSystemCertificates
  https://fedoraproject.org/wiki/Talk:Features/SharedSystemCertificates

I'm by no means an expert in this area but my impression is that the
PackagingDraft is made obsolete by the Shared System Certificates Feature.
As Killerix and Misc note on the talk page we should probably have some
packaging guidelines added that tell us what the expectations are.

The Guideline should answer the following questions:

* Should packages that ship their own cacerts be patched to use Shared
  System Certificates instead?  [I think the answer to this is yes]
* If the package contains a cacert that is not in our bundle, should those
  be added?
* How does a package add a cacert to our existing bundle?

Is there anyone available to write a draft for this and submit it to the
FPC (and answer questions that come up)?

-Toshio


pgpJYfjCdw6Tj.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: Removing python-setuptools-devel backwards compat

[Toshio Kuratomi]

On Mon, Nov 4, 2013 at 10:46 AM, Toshio Kuratomi  wrote:
>  I'd like to drop the
> backwards compatibility Provides (and Obsoletes) from the python-setuptools
> package.  However, there are currently 166 packages BuildRequire'ing
> python-setuptools-devel.

there's still 151 packages BuildRequireing python-setuptools-devel.

I've now created a F21 Change page for this:
https://fedoraproject.org/wiki/Changes/Remove_Python-setuptools-devel

The latest list of packages is at:
https://fedoraproject.org/wiki/User:Toshio/Packages_which_BuildRequire_python-setuptools-devel

Package owners were listed in the previous email:
https://lists.fedoraproject.org/pipermail/devel/2013-November/191344.html

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

Re: [Fedora-packaging] Proposal for Python guidelines change (in connection to Python 3 switch)

[Toshio Kuratomi]

On Wed, Dec 04, 2013 at 07:18:31AM -0500, Bohuslav Kabrda wrote:
> - Original Message -
> > Dne 4.12.2013 12:37, Bohuslav Kabrda napsal(a):
> > > (tkinter is actually a subpackage of python itself)
> > 
> > I guess you know what I mean here, but to be clear:
> > 
> > tkinter is only an example, we got more, like pyserial, PyYAML...
> 
> Oh, I see. Some time ago, FPC has accepted a change that says, that packages 
> with "py" in name should be prefixed with "python-" anyway [1]. Since this 
> only applies to newly created packages, we will have to cope with this, 
> unfortunately. So my idea of handling this would be:
> - all packages must have Provides: python-*
> - packages that weren't prefixed with "python-" previously (pyserial, 
> PyYAML), should also carry an explicit Provides/Obsoletes for the old name.
> Sounds good?
> 
I would remove that first bullet point.  The point of the Provides and
Obsoletes is to provide backwards compatibility.  If there's no previous
python-* there's no need to take up that name in the namespace.

> > Other thing:
> > 
> > What about apps? Do we want something in the guidelines that would say:
> > 
> > If the app clearly works with both Python 2 and Python 3,
> > then the Fedora package is obligated to use Python 3 instead
> > of Python 2.
> > 
> > If however the app only works with one of them, obviously,
> > Fedora package uses and requires that one.
> > 
> > Or do we keep that on the packager's decision?
> 
> Toshio already proposed a guidelines solution for this [2], but now that
> I look at it, it seems that it never got proposed to FPC. Toshio, will you
> propose that or should I? I guess we can do this regardless of the change
> I'm proposing now.
> 
> [2] 
> https://lists.fedoraproject.org/pipermail/python-devel/2013-November/000528.html
>
Please do.  I haven't got a whole lot of time these days :-(

-Toshio


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

Re: Kernel event library bundling

[Toshio Kuratomi]

On Thu, Nov 28, 2013 at 10:05:54PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> Hi, Florian.
> 
> On Thursday, 28 November 2013 at 11:38, Florian Weimer wrote:
> > There seems to be a library for processing kernel monitoring events
> > called "pevent", "libtrace", "traceevent" etc., which might
> > originally come from the kernel package (and is used there by perf),
> > but is copied at least into powertop and rasdaemon.
> > 
> > Does this fall under the scope of the "no bundled libraries" goal?
> 
> It might. Please file bugs against packages which do the bundling
> and make them block DuplicSysLibsTracker.
> 
If you don't want to unbundle the library from the other packages
ou'll want to file an FPC ticket as well.  I've pinged jwb about this
to see if the kernel guys have some information that might be relevant to
whether we should grant an exception or not.

-Toshio


pgpxuIql0G6n_.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: RFC: Simply the retirement procedure - trigger on dead.package

[Toshio Kuratomi]

On Wed, Nov 27, 2013 at 07:21:53PM +0100, Till Maas wrote:
> Hi,
> 
> while cleaning up retired packages (which I did not yet finish), I came
> up with an idea to simplify the retirement procedure to avoid
> inconsistencies. With the help of fedmsg I would like to make it enough
> wrt to koji and pkgdb to add a dead.package file to dist git to
> retire a package. When this happens, an automated process will retire
> the package in pkgdb and block the package in koji. This will make
> it impossible to only dead.package or only retire a package in pkgdb.
> 
> To avoid problems with lost messages from fedmsg, a regular cleanup job
> can download a git checkout and check for any missed dead.package files.
> 
> What are your opinions about this? I already checked with Dennis
> Gilmore, he is ok with this.
> 
> My plan is to  first setup a service that triggers the retirement in
> pkgdb and when this seems to work ask Infrastructure do disable retiring
> packages for regular users in pkgdb.
> 
Works for me -- depending on when this goes live, we might be making the
retirement change in pkgdb2 instead of pkgdb1.  (We're trying to get pkgdb2
live in January).  (And by we I mean pingou who is doing all of the hard
work on pkgdb2 ;-)

-Toshio


pgpO_LPE3npkS.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: Meeting minutes - today's Env-and-Stacks WG meeting (2013-11-19)

[Toshio Kuratomi]

On Mon, Nov 25, 2013 at 07:27:47AM -0500, Bohuslav Kabrda wrote:
> 
> So to get back to your question:
> - I'd like the WG to think about how we could support building extension 
> packages for multiple interpreters of dynamic languages - e.g. 
> Python+PyPy+Jython, Ruby+JRuby+Rubinius (this will probably need to be 
> coordinated with FPC).

Some relevant information for multiple python interpreters:
  https://fedoraproject.org/wiki/User:Toshio/Flock2013_Python_Guidelines#pypy

With Alex Gaynor's input I'm thinking that we probably have two choices
in this area:

1) Separate (sub)packages.  Similar to what python2, python3, and python26
   in EPEL5  stacks are doing.  Precedent wise, this likely makes the most 
sense.

2) Move to something like Debian does but maybe with less symlinks and
   maybe build-time instead of run-time .pyc creation.  dmalcolm rejected
   the Debian approach as too hacky.  To me it's a bit too complex for what
   it enables.  But perhaps the implementation could be simplified and made
   suitable for use in Fedora.  This would be a big departure from the past
   and would affect the main python stack as well as alternate interpreters
   so it is a much bigger and time consuming task to enable than the first
   alternative.

-Toshio


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

[Toshio Kuratomi]

On Thu, Nov 21, 2013 at 11:06:44AM +0100, Marcela Mašláňová wrote:
> On 20/11/13 20:23, Toshio Kuratomi wrote:
> >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
> >
> >
> >
> For now. I would be for more power to SIGs, because who does the work
> has the responsibility. I don't think people outside Java word can
> decide how it should be done.
> 
If we're talking about the same powers (I'm talking about Packaging  Guideline
approval) then I would be against giving that to SIGs for the same reasons
I gave in the Env and Stacks Meeting. Importance of precedence, importance
of big picture view of how it fits into Fedora and its policies.  SIGs come
up with what's expedient for them to package but that's not always the thing
that is going to make it easy for other packagers to get involved, end users
to use their packages, or advance Fedora's goals.

> I still don't see any reason, why should be Change proposal done
> differently. Could you sum it up in few points?

Not here, I'll continue to do that in the other part of the thread to not
get this tangent involved in it :-)

-Toshio


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

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

[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: 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: Using git for patch management in Fedora

[Toshio Kuratomi]

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.

-Toshio


pgp2ZlEZbZSlo.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: Packaing question: need some includes from kernel source

[Toshio Kuratomi]

On Tue, Nov 19, 2013 at 06:05:20PM +0100, Dridi Boukelmoune wrote:
> Maybe this should be added to an existing package. I forgot to mention
> that during a review I was told not to have multiple sources.
> 
  The main reason is so that the two packages can evolve independent of
each other.  You don't want to have to update your package because the other
source changed.  That would seem to apply here as well.

-Toshio


pgpINYcX0Jklg.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: Meeting minutes - today's Env-and-Stacks WG meeting (2013-11-19)

[Toshio Kuratomi]

On Tue, Nov 19, 2013 at 06:46:29PM +0100, Marcela Mašláňová wrote:
> 
> * PRD  (mmaslano, 16:19:29)
>   * LINK: http://piratepad.net/PwUiH4MEPR   (abadger1999, 17:04:53)
>   * ACTION: everyone to send one general thing they want the WG to
> enable and one specific thing they'd personally want to work on to
> the mailing list this week  (abadger1999, 17:37:44)
> 
Here's the backup copy of the piratepad session:

https://fedoraproject.org/wiki/User:Toshio/Env_and_Stacks_Charter_Brainstorming

I'm not sure how persistent or reliable piratepad is.  I'll look at syncing
from piratepad to the wiki again on Friday.

-Toshio


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

[Toshio Kuratomi]

On Tue, Nov 19, 2013 at 01:29:58PM -0500, Stephen Gallagher wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 11/19/2013 11:23 AM, Reindl Harald wrote:
> > Am 19.11.2013 17:15, schrieb Stanislav Ochotnicky:
> >>> I mean (and sorry that I wasn't clear), why the choice to make
> >>> java-headless the special case?  Especially if (as it appears
> >>> from the reply to Jerry James), most packages in Fedora will
> >>> only need the headless version.
> >>> 
> >>> (So the headless version would be the java package,  The
> >>> version with the gui nevironmen deps would be java-x11 or
> >>> similar).
> >> 
> >> If someone wanted to install just OpenJDK for their own in-house
> >> Java application they would have to know to request full -x11
> >> version. I would wager we'd be receiving a lot of bugs if we went
> >> this way. If someone needs headless they will be actively looking
> >> for it. If they want "java" they will not consider that they
> >> might get incomplete version. Not to mention possible 3rd party
> >> RPMs that might exist
> > 


> > 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.
>
I can see one advantage to this approach: it lets us tell packagers that
Requires: java should no longer be used.  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.

-Toshio


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

[Toshio Kuratomi]

On Tue, Nov 19, 2013 at 09:29:40AM +0100, Stanislav Ochotnicky wrote:
> Quoting Toshio Kuratomi (2013-11-18 17:08:12)
> > On Nov 15, 2013 4:09 AM, "Stanislav Ochotnicky" 
> > wrote:
> > >
> > > Quoting Jaroslav Reznik (2013-11-15 12:28:11)
> > > > * (optional) Mass-change spec files that have "Requires: java" to
> > "Requires:
> > > > java-headless"
> > > >
> > > > Other developers:
> > > > * Modify spec files to have "Requires: java-headless" instead of
> > "Requires:
> > > > java"
> > 
> > Could you say a few words about why a java-headless package was chosen
> > instead of java-x11 (as an example name)?
> > 
> 
> I believe the term was chosen because it's widely used term in Java world.
> Oracle uses that term in official documentation as well[1]. Last but not 
> least,
> Debian uses that term as well and I see no reason to be different just for the
> sake of it.
> 
I mean (and sorry that I wasn't clear), why the choice to make java-headless
the special case?  Especially if (as it appears from the reply to Jerry
James), most packages in Fedora will only need the headless version.

(So the headless version would be the java package,  The version with the
gui nevironmen deps would be java-x11 or similar).

-Toshio


pgpY1XGxzp3Tw.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: /usr/share/xsessions and window manager

[Toshio Kuratomi]

On Mon, Nov 18, 2013 at 01:41:22PM -0800, Adam Williamson wrote:
> byobu is the only
> one which appears to _only_ contain an applications file, but I've no
> idea what byobu is or whether that's sane.
>
IIRC, byobu is not an X1 window manager.  It's more like an enhancement or
pre-configuration of screen/tmux.

-Toshio


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

[Toshio Kuratomi]

On Nov 15, 2013 4:09 AM, "Stanislav Ochotnicky" 
wrote:
>
> Quoting Jaroslav Reznik (2013-11-15 12:28:11)
> > * (optional) Mass-change spec files that have "Requires: java" to
"Requires:
> > java-headless"
> >
> > Other developers:
> > * Modify spec files to have "Requires: java-headless" instead of
"Requires:
> > java"

Could you say a few words about why a java-headless package was chosen
instead of java-x11 (as an example name)?

-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

Re: BuildRequires: redhat-rpm-config

[Toshio Kuratomi]

On Thu, Nov 14, 2013 at 02:18:05PM +, Richard W.M. Jones wrote:
> On Thu, Nov 14, 2013 at 05:36:34PM +0800, Mathieu Bridon wrote:
> > For example, if right now you have:
> > 
> > %dir %{python_sitelib}/mymodule
> > %{python_sitelib}/mymodule/*.py
> > %{python_sitelib}/mymodule/*.pyc
> > %{python_sitelib}/mymodule/*.pyo
> > 
> > You could replace that by:
> > 
> > %{python_sitelib}/mymodule
> 
> Unfortunately the Python files are placed directly in
> %{python_sitelib} (not in a module subdirectory).  ie: the spec file
> has:
> 
> %files -n python-%{name}
> %doc python/examples/*.py
> %{python_sitearch}/*
> %{python_sitelib}/*.py
> %{python_sitelib}/*.pyc
> %{python_sitelib}/*.pyo
> 
> I have no idea if this packaging is correct or not.
> 
That is a somewhat odd split (somethings in sitearch and some things in
sitelib)

If there's nothing else in python_sitelib besides this module, you can
change the glob there:

  %{python_sitearch}/*
  %{python_sitelib}/*

I'd have to look at the actual package to know whether that would cause
problems.

-Toshio


pgprVcRMt2Iwt.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: [Fedora-packaging] Schedule for Thursday's FPC Meeting (2013-11-14 17:00 UTC)

[Toshio Kuratomi]

On Thu, Nov 14, 2013 at 06:39:25AM +0800, Christopher Meng wrote:
> Ticket #350 needs 2 votes on final decision.
> 
> Please consider.
> 
What would help is if you could add to the ticket what makes this different
from the situation of rsync bundling zlib or similar.  In order to be fair
to packagers, we try to either follow precedent in these cases or change the
guidelines so that old rejections would know that they could re-apply for an
exception if needed.

-Toshio


pgpRO8YCfn4VS.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: Schedule for Thursday's FPC Meeting (2013-11-14 17:00 UTC)

[Toshio Kuratomi]

On Wed, Nov 13, 2013 at 02:14:44PM -0500, James Antill wrote:
> 
> = Followups =
> 
> (approval and retirement sections already passed)
> #topic #339 software collections in Fedora
> .fpc 339
> https://fedorahosted.org/fpc/ticket/339
> 

I'm sorry, I don't think I'm going to get to anything new in the draft this
week as I'm having to work on talking to FHS about potential to modify /opt.

> (waiting on spot's input)
> #topic #352 BLAS and LAPACK packaging
> .fpc 352
> https://fedorahosted.org/fpc/ticket/352
> 
> #topic #355 How to package noarch packages which require a binary
> dependency which doesn't build on all archs?
> .fpc 355
> https://fedorahosted.org/fpc/ticket/355
> 
> #topic #357 time-api prior to openJDK8
> .fpc 357
> https://fedorahosted.org/fpc/ticket/357
> 
> = New business =
> 
FESCo was asked about enabling of third party repositories by the three
Products.  notting pointed out that the present policy is actually encoded
in a Packaging Guideline rather than in a FESCo Policy.  So we'll need to
discuss this so FESCo knows where we stand on it:
https://fedorahosted.org/fpc/ticket/366

-Toshio


pgpCNAdN_zkyf.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: Schedule for Wednesday's FESCo Meeting (2013-11-13)

[Toshio Kuratomi]

On Tue, Nov 12, 2013 at 08:34:28PM -0700, Kevin Fenzi 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 '2013-10-23 18:00 UTC'
> 
> Links to all tickets below can be found at: 
> https://fedorahosted.org/fesco/report/9
> 
> = Followups =
> #topic #1185 Enable "-Werror=format-security" by default
> .fesco 1185
> https://fedorahosted.org/fesco/ticket/1185
> 
> = New business =
> 
> #topic #1195 WG autonomy
> .fesco 1195
> https://fedorahosted.org/fesco/ticket/1195
> 
> #topic #1196 Set deadline for PRDs
> .fesco 1196
> https://fedorahosted.org/fesco/ticket/1196
> 
> #topic #1198 Possible changes to Fedora EOL bug procedure
> .fesco 1198
> https://fedorahosted.org/fesco/ticket/1198
> 
> #topic #1199 Ratify Base Working Group governance charter
> .fesco 1199
> https://fedorahosted.org/fesco/ticket/1199
> 
Env and Stacks governance document has also just been completed if we have
time it's here:

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

-Toshio


pgprGOgO1S1OS.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: How to handle non-free parts of a free software project

[Toshio Kuratomi]

On Tue, Nov 12, 2013 at 12:22:16AM +0200, Elad Alfassa wrote:
> 
> On Tue, Nov 12, 2013 at 12:13 AM, Manuel Faux  wrote:
> 
> NetBeans 7.4 requires a file called jnlp-servlet.jar which is part of
> the Oracle JDK and itself non-free licensed. The file is not required
> for building, but for specific functions of the software. 
> 
> 
> More concrete, the file is required if "one wants to build a packaged
> war file of JNLP version of a suite".
> 
> It seems like only the class jnlp.sample.servlet.JnlpDownloadServlet is
> required, but I could not find it in the OpenJKD.
> 
> How is this normally handled? Should we add a file to the docs which
> describes that for this specific functionality that file is required?
>
> Manuel
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> 
> 
> 
> The answer is simple. Remove the file. Don't distribute it in Fedora. Have a
> README.fedora file in /usr/share/docs/netbeans (or whatever) which explains
> that this file was removed due to licensing issues and how to get it.
> 
Depending on the license, you may just need to remove the file in the spec
file or you may need to clean it from the tarball before that tarball is
uploaded to the lookaside cache (via fedpkg new-sources).

You may also need to patch the software so that it gracefully handles the
lack of that file at runtime.  Perhaps removing the menu entry that won't
function or popping up a dialog to explain that the netbeans we ship can't
use that non-free functionality.

-Toshio


pgpz4PfhtTAq1.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: python-setuptools update in F20

[Toshio Kuratomi]

On Mon, Nov 4, 2013 at 12:44 PM, Toshio Kuratomi  wrote:
> A new setuptools upstream release (1.2) was made last week that adds support 
> for
> subversion 1.7 and 1.8.  Subversion 1.7 shipped in Fedora 19 so the
> subversion support in setuptools is currently broken in both F19 and F20.
> Unless there's objections I'm definitely going to update setuptools in F20.
> I'm quite hesitant about updating in F19 due to potential incompatibilities.
> In particular, pip, buildout, and virtualenv would likely all need to update
> (these were things that we found had minimum versions to work with the F20
> setuptools package as per:
> https://fedoraproject.org/wiki/Changes/Python_setuptools_0.7
> )
>
> Backwards incompatible changes were introduced between 0.9.8 and 1.0:
> https://pypi.python.org/pypi/setuptools#id145 but these changes are unlikely
> to affect any code that's currently in the wild.
>
> Please speak now if you don't want this update to hit F20 or do want the
> update to hit F19.  My plan is to update the python-setuptools package in
> F20 to 1.3 near the end of this week.
>
This update has now been submitted:
https://admin.fedoraproject.org/updates/python-setuptools-1.3.1-1.fc20
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Summary/Minutes for Wednesday's FESCo Meeting (2013-11-06)

[Toshio Kuratomi]

==
#fedora-meeting: fesco
==


Meeting started by abadger1999 at 18:02:39 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting/2013-11-06/fedora-meeting.2013-11-06-18.02.log.html
.



Meeting summary
---
* Roll Call  (abadger1999, 18:02:59)

* #1185 Enable "-Werror=format-security" by default  (abadger1999,
  18:04:46)
  * Adding to gcc's -Wall as a local Fedora patch was rejected
(abadger1999, 18:08:12)
  * Deferred another week awaiting results of mass rebuild
(abadger1999, 18:08:45)

* #1192 OpenH264 as an automatic download by firefox/Statement to the
  ietf WebRTC working group  (abadger1999, 18:08:58)
  * LINK: https://fedorahosted.org/fesco/ticket/1192#comment:8
(abadger1999, 18:12:45)
  * additional text from pjones approved (+1:7, 0:0, -1:0)
(abadger1999, 18:39:05)
  * ACTION: abadger1999 to take care of sending the statement to the
ietf.  (abadger1999, 18:40:38)

* #1191 Fedora 20 schedule adjustment  (abadger1999, 18:42:00)
  * Move up the final freeze by one week passed (+1:7, 0:0, -1:1)
(abadger1999, 18:51:11)

* #1194 Ratify Server Working Group governance charter  (abadger1999,
  18:51:54)
  * Server working group governance charter approved (+1:8, 0:0, -1:0)
(abadger1999, 18:55:37)

* #1193 reboots for all updates -- are we ready for this?  (abadger1999,
  18:55:56)
  * Change owners are trusted to, _and dependent upon_, highlight all
relevant changes.  Not noting important changes (whether due to
oversight or intentionally) breaks the Change process, and would
sadly motivate FESCo to institute a more heavy-handed and
higher-overhead process, which nobody wants to have.  (mitr,
19:22:54)
  * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1001335
(jreznik, 19:23:51)
  * mitr's proposal to update change policy passed (+1:5, 0:0, -1:1)
(abadger1999, 19:40:45)
  * Proposal to Keep F20 behavior as-is (all offline updates for gnome).
Update Change page to reflect current implementation, update docs
and release notes to match.  Passed (+1:5, 0:2, -1:0)  (abadger1999,
19:43:30)

* #1189 Stalled bug 758826 -- requesting intervention  (abadger1999,
  19:46:21)
  * twoerner working on an update.  Will update the bug report.
(abadger1999, 19:50:39)

* Open floor  (abadger1999, 19:50:45)

* F21 Change Process  (abadger1999, 19:51:20)
  * F21 Change Process is open for submissions  (abadger1999, 19:52:15)

* Elections  (abadger1999, 19:52:23)
  * jreznik will send an announcement that we're seeking an Election
Wrangler.  (abadger1999, 19:53:56)

* Next week's Chair  (abadger1999, 19:54:05)
  * nirik to chair next week's meeting  (abadger1999, 19:55:03)

* Open Floor  (abadger1999, 19:55:10)
  * Regarding the earlier discussion on OpenH264, if Fedora community
members have a project in Fedora that is intending to use OpenH264
in some way, please talk to FESCo before integrating code to use it.
(notting, 20:02:39)

Meeting ended at 20:06:34 UTC.




Action Items

* abadger1999 to take care of sending the statement to the ietf.




Action Items, by person
---
* abadger1999
  * abadger1999 to take care of sending the statement to the ietf.
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* abadger1999 (159)
* nirik (70)
* mattdm (60)
* sgallagh (57)
* pjones (48)
* notting (47)
* mitr (46)
* adamw (38)
* mclasen (33)
* jreznik (24)
* t8m (21)
* drago01 (13)
* zodbot (10)
* twoerner (7)
* jwb (7)
* mmaslano (6)
* jreznik2 (2)
* masta (1)
* Southern_Gentlem (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-- 
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-06)

[Toshio Kuratomi]

On Wed, Nov 06, 2013 at 03:52:11PM +, Richard W.M. Jones wrote:
> On Wed, Nov 06, 2013 at 07:16:23AM -0800, Toshio Kuratomi wrote:
> > On Wed, Nov 06, 2013 at 01:05:22PM +, Richard W.M. Jones wrote:
> > > On Tue, Nov 05, 2013 at 10:19:12PM -0800, Toshio Kuratomi wrote:
> > > > #topic #1193 reboots for all updates -- are we ready for this?
> > > > .fesco 1193
> > > > https://fedorahosted.org/fesco/ticket/1193
> > > 
> > > Didn't this terrible idea die already?
> > >
> > Do you have a link to the discussion/decision for this?
> > 
> > I've been looking around for the prior discussion and thus far I've found:
> > https://fedorahosted.org/fesco/ticket/869
> > https://fedoraproject.org/wiki/F18_release_announcement?stF18#For_systems_administrators
> > 
> > (Base feature approved for F18.)
> 
> Previous discussion:
> 
> https://lists.fedoraproject.org/pipermail/devel/2012-June/thread.html#168689
> 
> https://lists.fedoraproject.org/pipermail/devel/2013-February/thread.html#178112
> 
Thanks.

Those seem to be discussion of the cons and pros, though, rather than
a decision.  So the discussion is relevant in that one of the important
compromise points was that previously it only applied to a subset of
updates but nothing says that the idea was "dead" as in rejected for
Fedora, correct?

In other words, I just want to make sure status quo before AppInstaller is
that Offline Updates are live on Fedora's Gnome Desktop but only for "OS
Components"?

-Toshio


pgpsETvhTaSqz.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: Schedule for Wednesday's FESCo Meeting (2013-11-06)

[Toshio Kuratomi]

On Wed, Nov 06, 2013 at 01:05:22PM +, Richard W.M. Jones wrote:
> On Tue, Nov 05, 2013 at 10:19:12PM -0800, Toshio Kuratomi wrote:
> > #topic #1193 reboots for all updates -- are we ready for this?
> > .fesco 1193
> > https://fedorahosted.org/fesco/ticket/1193
> 
> Didn't this terrible idea die already?
>
Do you have a link to the discussion/decision for this?

I've been looking around for the prior discussion and thus far I've found:
https://fedorahosted.org/fesco/ticket/869
https://fedoraproject.org/wiki/F18_release_announcement?stF18#For_systems_administrators

(Base feature approved for F18.)

-Toshio


pgpg1_hZvm484.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: Schedule for Wednesday's FESCo Meeting (2013-11-06)

[Toshio Kuratomi]

On Wed, Nov 06, 2013 at 07:38:18AM -0500, Jaroslav Reznik wrote:
> 
> Please, add also 
> 
> #topic #1191 Fedora 20 schedule adjustment
> .fesco 1191
> https://fedorahosted.org/fesco/ticket/1191
> 
Added.

I scheduled this in right after the OpenH264 ticket because it also needs to
be decided on in a timely fashion.

-Toshio


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

Schedule for Wednesday's FESCo Meeting (2013-11-06)

[Toshio Kuratomi]

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 '2013-11-06 18:00 UTC'


Links to all tickets below can be found at: 
https://fedorahosted.org/fesco/report/9

= Followups =

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

= New business =

#topic #1192 OpenH264 as an automatic download by firefox/Statement to the ietf 
WebRTC working group
.fesco 1192
https://fedorahosted.org/fesco/ticket/1192

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

#topic #1188 Stalled bug 560361 -- requesting intervention
.fesco 1188
https://fedorahosted.org/fesco/ticket/1188

.bug 560361
Dhclient doesn't use client-identifier; may cause issues in certain bridged 
environments
https://bugzilla.redhat.com/show_bug.cgi?id=560361


#topic #1189 Stalled bug 758826 -- requesting intervention
.fesco 1189
https://fedorahosted.org/fesco/ticket/1189

.bug 758826
system-config-firewall should include 'submission' in list of known ports
https://bugzilla.redhat.com/show_bug.cgi?id=758826


#topic #1194 Ratify Server Working Group governance charter
.fesco 1194
https://fedorahosted.org/fesco/ticket/1194

= Open Floor = 

For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at
https://fedorahosted.org/fesco/report/9

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/fesco,
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. 

-Toshio


pgporQfJIY7kI.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: Packaging Python 3.4.0

[Toshio Kuratomi]

On Tue, Nov 05, 2013 at 07:29:35AM -0500, Bohuslav Kabrda wrote:
> Hi all,
> I started working on updating python3 to 3.4.0. So far, this is only in
> a private branch "python3.4" in dist-git, since I'll need to get a Change
> approved for Fedora 21. I already created the Change [1], but I was told
> that it will get on FESCo schedule when Fedora 21 schedule and future is
> more clear, so for now I'll just work on Python 3.4.0.
>
Hmmm Putting on a fesco hat, I would be more than willing to approve
changes for F21 now We've already approved Python3 as Default which has
both F21 and F22 goals.

I think that the F21 Schedule and Product desciptions are somewhat
orthogonal to some features including this.  The things I'm looking at that
imply that are:

* Something that either is non-specific to one of our products
* Something that is an upgrade of packages already in Fedora

So in my view -- submit the Change! :-)

> When Python 3.4.0 reaches beta1 (which means feature freeze, which also
> means that the bytecode format should no longer change) - November 24 [2]
> - I plan to create a repo in Copr so that everyone has access to built
> RPMs, and also I want to start rebuilding as many packages as possible to
> see how they work with Python 3.4.
>
 The rebuilding make me want to get this into the main repos early.

> As for the current state of Python 3.4 in the dist-git branch:
> - It still seems a bit unclear what upstream will do with the sha3
>   implementation (although they will probably keep it), so I didn't rebase
>   the fips patch yet, there is still plenty of time for that.

I think Christian outlined what they are going to do with sha3 yesterday
(but yeah, it depends on what is happening with the sha3 standard so there's
a bit of uncertainty there still).

> - pep453 [3] (pip bootstraping) hasn't been implemented yet. The pep also
>   contains recommendation for distro packagers, so here's what we should do.
> -- Make a circular dependency between python3 and python3-pip (ugly, will
>require bootstraping with every new Python minor version).
>
Do you mean minor version as in the "4" in 3.4 or as in the micro level ("0"
in 3.4.0)?

We can get around bootstrapping at minor version revs if pip is only used at
runtime, not at buildtime.

We can still get around bootstrapping at micro version if we are careful
never to include pip's code in the package.  Only figure out where to find
pip's code.

> -- Definitely delete bundled CA certificates and use system certificates
>instead.

+1

> -- Maybe remove the bundled pip (although this goes against the pep) and
> use python3-pip. E.g. everything would work as expected, but under the
> wraps, python3-pip package would be used. So when doing security updates,
> we'd just fix python3-pip. It is however true that if Fedora's pip would
> be different from the upstream bundled one, users may experience some
> behaviour differencies. I'd like to hear your opinions on how we should
> approach this.
>
We should definitely do this.  pip itself bundles code that we've had to
unbundle locally -- maintaining that morass of software again (it's also
bundled inside of virtualenv...) is going to lead to a lot of work anytime
an update needs to happen.

However, talking with ncoghlan it may not be simple.  The case that makes
things tricky is pyvenv.  Upstream python wants to protect venv's from
changes to code on the system.  ie: if a user installs a backwards
incompatible pip on the system, that should not affect the pip inside the
existing venvs.  Equally, if there are security issues found with pip, those
changes would not be propogated to the pip inside the venvs.

ncoghlan proposed that we create wheels in the pip package (and all the
packages that pip bundles that we have to unbundle) and then when ensurepip
installs into a venv, it copies those wheels in there.

I'm wondering if we could do a little better.  Instead of keeping around two
copies of all this software on the system, if we can reconstruct a wheel zip
(or possibly just copy the files in) from the wheel metadata and files on
the system.   I know that sysadmins and developers will hotfix software on
the system for issues that they care about.  Having those changes propogate
to newly installed venvs seems like a better plan than having the venvs get
the old copies that were built at rpm build time.

-Toshio


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