Re: $PYTHONPATH

2012-04-21 Thread Toshio Kuratomi
On Sat, Apr 21, 2012 at 06:17:21PM -0700, Rob Healey wrote:
> Greetings:
> 
> This is probably a very naive/ general question, but I still do NOT
> know the answer???
> 
> I need to make a permanent addition to the $PYTHONPATH variable!  I
> need to append to the environment variable...
> 
> I knowe in the python interactive command line:
> 
> import os
> sys.path.append(os.getcwd()) works in python, but I need to append to
> this variable from the command line or from my .bashrc file ...
>
The PYTHONPATH environment variable is what you probably want

for instance in .bashrc:

export PYTHONPATH=/home/badger/my/python/directory

-Toshio


pgpqskRFgyix8.pgp
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Update to Infrastructure, help catch problems before beta

2012-04-16 Thread Toshio Kuratomi
* Note:  For FESCo and QA, this is just an FYI

Fedora Infrastructure uses the puppet configuration management software to
push configuration files out to all of its machines.  A new release of puppet
has been created and pushed out to the EPEL repositories today.  This release
includes several security fixes [1]_ that we have decided are very important for
us to apply.  Due to that, we are going to be updating puppet on all of our
machines.

We're sending this message out to alert you to the potential for disruptions
from this, including disruptions that could slip the Fedora Beta release.  We
do not anticipate such problems because the actual changes to the puppet code
should be rather small.  We're not even anticipating any interruption of
services.  However, this update is going out to all of our machines so we want
people to be aware that problems could occur and if they experience any
problems in the critical path to releasing the Beta on time to report them to
us ASAP [2]_.

.. [1]_: 
http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.6.15

.. [2]_: Contact us in #fedora-admin on irc.freenode.net, via our ticketing
system at https://fedorahosted.org/fedora-infrastructure , or our mailing
list: infrastruct...@lists.fedoraproject.org

Thank you,
Your friendly neighborhood infrastructure team



pgpwFw4v5RPAw.pgp
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F15 yum update pblm

2011-04-13 Thread Toshio Kuratomi
On Wed, Apr 13, 2011 at 08:52:31AM -0500, Steven Stern wrote:
> Problem or temporary thing?  Attemping an update this morning:
> 
> Error: Package: elinks-0.12-0.24.pre5.fc15.i686 
> (@anaconda-InstallationRepo-201102260129.i686/15-Alpha)
> Requires: libjs.so.1
> Removing: js-1.70-13.fc15.i686 
> (@anaconda-InstallationRepo-201102260129.i686/15-Alpha)
> libjs.so.1
> Updated By: 1:js-1.8.5-3.fc15.i686 (updates-testing)
> Not found
>   You could try using --skip-broken to work around the problem

This one is a problem.  Maintainer has been contacted but needs some
training on SONAMES (or at least SONAME detection in rpm) before his
fix actually works.  Hopefully it'll be straightened out today or tomorrow.

-Toshio


pgpMZZyDSgVZx.pgp
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: systemd: how to list enabled services

2011-03-28 Thread Toshio Kuratomi
On Mon, Mar 28, 2011 at 01:47:33PM -0400, Bill Nottingham wrote:
> Ian Pilcher (arequip...@gmail.com) said: 
> > > According to the wiki, chkconfig should work with systemd.  Doesn't it?
> > > 
> > > http://fedoraproject.org/wiki/Systemd#Does_chkconfig_command_work_with_systemd.3F
> > 
> > Running "chkconfig --list" prints this warning:
> > 
> > Note: This output shows SysV services only and does not include native
> >   systemd services. SysV configuration data might be overriden by native
> >   systemd configuration.
> 
> To be precise, the following commands in chkconfig have systemd integration:
> 
> - on (to enable a service)
> - off (to disable a service)
> -  (to check whether a single passed service is enabled)
> 
Note that these are integrated into systemd but they change the behaviour of
chkconfig.

on and off map to systemctl enable whereas chkconfig would set the service
on and off in certain runlevels.  So they're now more similar to chkconfig
--add.

The  case doesn't check targets like chkconfig does with
runlevels.

People who are scripting with chkconfig are going to need to update their
scripts.

-Toshio


pgpQwPc7L21xP.pgp
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: systemd: how to list enabled services

2011-03-28 Thread Toshio Kuratomi
On Sat, Mar 26, 2011 at 12:06:47PM -0500, Ian Pilcher wrote:
> On 03/25/2011 11:30 PM, Toshio Kuratomi wrote:
> > On Fri, Mar 25, 2011 at 11:05:21PM -0500, Ian Pilcher wrote:
> >>
> >> chkconfig --list | grep :on
> >>
> >> What is the systemd (systemctl equivalent)? 
> > 
> > ls /etc/systemd/system/*.wants/frobozz.service
> > 
> > https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet
> > 
> 
> No.  According to the cheatsheet, that is the equivalent of:
> 
> chkconfig frobozz --list
> 
> So my question still stands.
> 
Oops --

ls /etc/systemd/system/*.wants/

I see that further into the thread some people found another command that
seems to do what's needed without resorting to ls on the filesystem.  If
that's the case, then it should be added to the wiki.  Note that I have no
experience with that command so one thing to check is that it matches up
with the output from the "ls" command.  chkconfig --list isn't checking the
currently running services with this command but the services that will be
enabled in any runlevel (roughly a systemd target) should we be switched
into that runlevel.

-Toshio


pgpwbr6oKZTmq.pgp
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: systemd: how to list enabled services

2011-03-25 Thread Toshio Kuratomi
On Fri, Mar 25, 2011 at 11:05:21PM -0500, Ian Pilcher wrote:
> I'm in the habit of running
> 
> chkconfig --list | grep :on
> 
> to list all of the services that are enabled on my system (usually right
> after an installation, so I can disable all of the stuff that I don't
> need).
> 
> What is the systemd (systemctl equivalent)? 

ls /etc/systemd/system/*.wants/frobozz.service

https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet

Note that because systemd uses dependencies to tell what needs to be
started, some services may start that aren't listed there if one of the
listed services depends on it.

-Toshio


pgpkqT6oHCVi6.pgp
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [HEADS-UP] PostgreSQL 9.0.2 now in rawhide

2010-12-29 Thread Toshio Kuratomi
On Tue, Dec 28, 2010 at 07:36:35PM -0500, Tom Lane wrote:
> I have pushed PostgreSQL 9.0.2 into rawhide, replacing the 8.4.x release
> series.
> 
> As is usual with PostgreSQL major version updates, 9.0.x won't read
> 8.4.x's database files.  However, this time around there is an option
> to not have to dump and reload your database: you can try pg_upgrade
> instead.  The details are in
> /usr/share/doc/postgresql-9.0.2/README.rpm-dist
> but the short form is: install postgresql-upgrade and run
> "service postgresql upgrade".
> 
> This isn't terribly well tested, so if you're running critical data
> on rawhide (you aren't, are you?) a traditional-form backup would be
> a good thing to make first.
> 
> Please let me know of either successful or unsuccessful upgrades.
> 
Yay!  Glad to see you and the other upstream guys got this implemented.

I know some people were talking about making systemd unit files for
a significant subset of services one of the features for F15.  I do not,
however, see a Feature page (even an incomplete Feature page) for that yet.

Would someone who is working on that care to say if that's still an idea for
F15?  If it goes through, we'll want to document what service postgresql
upgrade does for people to run (or turn it into a /usr/bin/ script) since
we'll be moving away from the sysvinit script.

(Also, we should either make a new Feature page for porting services to unit
files or we should make explicit that we're undertaking that task if that's
the plan for F15).

-Toshio


pgpOwyEg4nHNl.pgp
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: warning to deltaiso users running Rawhide

2010-10-21 Thread Toshio Kuratomi
On Thu, Oct 21, 2010 at 11:37:44PM +0200, Thomas Spura wrote:
> 
> new-xz hit the builders and all packages since then will use the new
> format. With the next yum update, you get:
> - the packages deltas with old-xz (which you didn't got already, but
>   that doesn't matter, because you still have the old xz) and
> - the packages deltas with new-xz, which will have the md5 mismatch
> 
> After that update, you only get package deltas with new-xz (or the
> complete package, because it's not yet installed on your system), so it
> should be only on *one* next yum update.
> 
Ah I see -- I was thinking of a different corner case which after thinking
it through is actually less likely to occur.

User has new xz but isn't entirely up to date.  Does an update of
remaining packages, all of the packages which have not been rebuilt since
the new xz hit the buildroot will fail with a checksum mismatch.

The starting condition -- xz updated but other packages outdated, seems less
likely to occur.

-Toshio


pgpvH18iKhLnl.pgp
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: warning to deltaiso users running Rawhide

2010-10-21 Thread Toshio Kuratomi
On Thu, Oct 21, 2010 at 11:04:42PM +0200, Thomas Spura wrote:
> On Thu, 21 Oct 2010 14:47:31 -0600
> Michal Jaegermann wrote:
> 
> > On Thu, Oct 21, 2010 at 05:20:04PM +, Andre Robatino wrote:
> > > I only saw
> > > that for a few packages on October 18 (as mentioned in bug 644046),
> > > and not since, including today's Rawhide updates. So all or most of
> > > the older RPMs should already have been pushed.
> > 
> > I got this "md5 mismatch" error today for deltas of glibc-2.12.90-17
> > rawhide packages which were built on October 19th.
> 
> I think, *everyone* will get this error, with the next update after the
> new xz hit the builders itself (and not yet the users).
> 
> After that both the builders and the users are only seeing new
> generated deltas with the new xz.
> So ignoring it once and then it should work again, isn't it?
> 
Once for every package?  Or do you mean just the next yum update?

-Toshio


pgpd4aAh2D8my.pgp
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: warning to deltaiso users running Rawhide

2010-10-21 Thread Toshio Kuratomi
On Thu, Oct 21, 2010 at 11:33:36AM +, Andre Robatino wrote:
> A version of xz (4.999.9-0.3.beta.212.gacbc.fc15) which compresses differently
> from the versions in F11 to F14 was recently pushed to Rawhide. This has the
> side effect of making existing deltaisos not work properly if the newer 
> version
> of xz is installed. (At the end of running applydeltaiso, one would get an
> "md5sum mismatch, iso is corrupt" error, and the ISO would be unusable.) For
> Rawhide users, to use a deltaiso between versions <= 14, do the following:
> 
> 1) temporarily downgrade all xz-\* packages to the F14 versions (currently
> 4.999.9-0.2.beta.20100401git.fc14) which are available in
> http://download.fedoraproject.org/pub/fedora/linux/development/14/{i386,
> x86_64}/os/Packages/. I suggest saving the necessary RPMs in one's home
> directory to make switching easy.
> 
> 2) Run applydeltaiso as usual. If you get an "iso successfully re-created"
> message at the end then all is well.
> 
> 3) Restore the original xz-\* packages (which are necessary for Rawhide's 
> drpms
> to rebuild properly when updating).
> 
> The xz developer says that the new version of xz will not be pushed to F14 and
> below (see https://bugzilla.redhat.com/show_bug.cgi?id=644046 ). I still need 
> to
> update the deltaiso documentation at https://fedoraproject.org/wiki/Delta_ISOs
> and https://fedoraproject.org/wiki/User:Robatino/Downloads . I don't know yet
> exactly how this will affect deltaisos after F14 Final.
> 
Question -- will we need to mass rebuild all Fedora 15 packages with the new
xz so that delta* rpm stuff works?

-Toshio


pgpmpL6v7v7LI.pgp
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F-14 Branched report: 20100923 changes

2010-09-24 Thread Toshio Kuratomi
On Fri, Sep 24, 2010 at 05:43:47PM +0100, Peter Robinson wrote:
> On Fri, Sep 24, 2010 at 5:34 PM, Toshio Kuratomi  wrote:
> > On Fri, Sep 24, 2010 at 02:44:34PM +0100, Richard W.M. Jones wrote:
> >> On Thu, Sep 23, 2010 at 07:01:16PM +0100, Peter Robinson wrote:
> >> > Is it really necessary to include entire package change logs in the
> >> > rpm changelog? What is wrong with referencing either the included
> >> > changelog or a URL to a changelog that people can go and reference. I
> >> > remember this being discussed ages ago but I'm not sure if there was a
> >> > packaging policy instigated.
> >>
> >> Along the same lines, why should we have RPM %changelog at all?  The
> >> git repo should maintain the changelog which can be automatically
> >> integrated with the binary RPM at build time.  At the moment we have
> >> the same information in at least 2 places.
> >>
> > We need to have the rpm changelog in the rpm so that the end user's can see
> > it.
> 
> For the fact that its gone from version X to version Y yes.

Actually, this is normally reflected in the package version which is quite
visible.

> For the
> actual application changed between version X and version Y they can
> see the ChangeLog that's in the %doc or alternatively check the
> release notes for the new version upstream (which can be easily
> provided as a link in the rpm changelog).

rpm -q --changelog
repoquery -q --changelog

Very handy for asking and answering the questions like:

foobar started segfaulting.  yum history tells me I updated it, libbaz, and
libzardoz.  Any changes in those that could have caused this?

I'm having problems with foobar not being able to connect to https://.
I wonder if the new update in updates-testing might fix that?

> I just don't see the point
> in duplicating hundreds of line of upstream release notes in the rpm
> changelog when all that's actually changed in the rpm is that we've
> gone from release X to release Y.
>
I agree that duplicating hundreds of lines is not productive.  To me the rpm
changelog should give me enough information to know if I might be on the
right track when I ask the questions above.  Having hundreds of lines of
changelog per entry is counter-productive to that goal:: If I have to wade
through hundreds of lines for each of foobar, libbaz, and libzardoz I might
well miss that one of the changelog entries addressed the problem I'm
looking for.

The rpm changelog should be more like NEWS than a changelog; and usually
a summary of NEWS, at that.  (imho, no packaging guidelines currently
mandate this, etc.)

-Toshio


pgpeZ7rrdHmHE.pgp
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F-14 Branched report: 20100923 changes

2010-09-24 Thread Toshio Kuratomi
On Fri, Sep 24, 2010 at 07:21:21AM +0200, Andrew Beekhof wrote:
> On Thu, Sep 23, 2010 at 9:47 PM, Bruno Wolff III  wrote:
> > On Thu, Sep 23, 2010 at 14:21:12 -0400,
> >  Toshio Kuratomi  wrote:
> >>
> >> Rather than a guideline, Andrew, would you just consider summarising the
> >> important changes for the rpm changelog from now on?
> >
> > For myself, I like to note the more important changes and provide a link
> > back to a detailed list if upstream provides one.
> >
> 
> In this case I am upstream and believe me, that _was_ the abbreviated version.
> I can certainly look to reduce it further, but I find that it
> shortcuts a lot of "what changed" questions.

Perhaps Bruno's suggestion to do something like:

* Fix numerous issues in foobar's parser and renderer including one
  potential segfault and numerous places where random characters would show
  up on the screen.  For details see:
  http://www.foobar.org/docs/changelog#1.0

would be best here.  end users are always going to want to know if their
particular bug was fixed but too much extraneous information is as bad as
too little.  If you can mention just enough specifics so that the
"try-it-and-see" people can say, ah ha, I was seeing those symptoms, let me
see if this works will be happy.  If you make it easier to visit the link
for complete details than it is to send you an email then those who want to
be sure that their issue has been resolved before they update will also get
what they want without bothering you.

-Toshio


pgpOGyzK8vM0I.pgp
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F-14 Branched report: 20100923 changes

2010-09-24 Thread Toshio Kuratomi
On Fri, Sep 24, 2010 at 02:44:34PM +0100, Richard W.M. Jones wrote:
> On Thu, Sep 23, 2010 at 07:01:16PM +0100, Peter Robinson wrote:
> > Is it really necessary to include entire package change logs in the
> > rpm changelog? What is wrong with referencing either the included
> > changelog or a URL to a changelog that people can go and reference. I
> > remember this being discussed ages ago but I'm not sure if there was a
> > packaging policy instigated.
> 
> Along the same lines, why should we have RPM %changelog at all?  The
> git repo should maintain the changelog which can be automatically
> integrated with the binary RPM at build time.  At the moment we have
> the same information in at least 2 places.
> 
We need to have the rpm changelog in the rpm so that the end user's can see
it.  We could generate one of the changelogs automatically, though.  I would
much prefer to generate the git log from the rpm changelog than vice-versa,
though.  THe git log is going to contain more entries than the rpm changelog
as little things get fixed from time to time that deserve a commit in git
but don't deserve a mention in the rpm changelog.


This should be pretty easy to do in fedpkg commit by having that perform its
fedpkg clog action and then automatically adding that information into what
the git message will be... in fact, I haven't used fedpkg commit, it might
already do this.  If not, care to send a patch?

-Toshio


pgpoQzWQVKWIP.pgp
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F-14 Branched report: 20100923 changes

2010-09-23 Thread Toshio Kuratomi
On Thu, Sep 23, 2010 at 07:01:16PM +0100, Peter Robinson wrote:
> Is it really necessary to include entire package change logs in the
> rpm changelog? What is wrong with referencing either the included
> changelog or a URL to a changelog that people can go and reference. I
> remember this being discussed ages ago but I'm not sure if there was a
> packaging policy instigated.
> 
There wasn't -- in general I don't like to pursue really stylistic stuff
like this as a guideline.  If you'd like to push a draft, though, the FPC
will consider it.

Rather than a guideline, Andrew, would you just consider summarising the
important changes for the rpm changelog from now on?

Thanks,
-Toshio


pgpm9on6MJod9.pgp
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F-14 Branched report: 20100915 changes

2010-09-15 Thread Toshio Kuratomi
On Wed, Sep 15, 2010 at 11:52:50AM -0400, David Malcolm wrote:
> On Wed, 2010-09-15 at 11:46 -0400, Bill Nottingham wrote:
> > Toshio Kuratomi (a.bad...@gmail.com) said: 
> > > > python-psyco-1.6-4.fc12.i686 requires libpython2.6.so.1.0
> > > > python-psyco-1.6-4.fc12.i686 requires python(abi) = 0:2.6
> > > 
> > > My understanding on this was that psyco was broken on python-2.7... Do we
> > > want to block this from the F14 release?
> > 
> > Does anything else require it?
> IIRC, eclipe-pydev did, but removed it, only using it for optimization.
> 
F14 vm:
% repoquery -q --whatrequires 'python-psyco' --alldeps
python-psyco-0:1.6-4.fc12.i686

So it looks safe to remove in f14.

-Toshio


pgpXG33eTWNyT.pgp
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F-14 Branched report: 20100915 changes

2010-09-15 Thread Toshio Kuratomi
On Wed, Sep 15, 2010 at 03:19:46PM +, Branched Report wrote:
>   python-polybori-0.5-8.fc14.i686 requires libboost_python.so.1.41.0

I rebuilt this and submitted an update.  This warning should go away in
a week or so when we push to stable.

>   python-psyco-1.6-4.fc12.i686 requires libpython2.6.so.1.0
>   python-psyco-1.6-4.fc12.i686 requires python(abi) = 0:2.6

My understanding on this was that psyco was broken on python-2.7... Do we
want to block this from the F14 release?

-Toshio


pgpxTRV21eWJo.pgp
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: rawhide report: 20100901 changes

2010-09-01 Thread Toshio Kuratomi
On Wed, Sep 01, 2010 at 12:20:34PM +, Rawhide Report wrote:
>   python3-PyQt4-4.7.4-2.fc14.i686 requires python(abi) = 0:3.1
>   python3-PyQt4-4.7.4-2.fc14.x86_64 requires python(abi) = 0:3.1
>   python3-PyQt4-devel-4.7.4-2.fc14.i686 requires python(abi) = 0:3.1
>   python3-PyQt4-devel-4.7.4-2.fc14.x86_64 requires python(abi) = 0:3.1
>   python3-beaker-1.5.3-5.fc14.noarch requires python(abi) = 0:3.1
>   python3-coverage-3.3.1-3.fc14.x86_64 requires 
> libpython3.1.so.1.0()(64bit)

These require rebuilds in rawhide due to rawhide moving to Python-3.2.  I'm
unsure at this point if some of them need porting as well.

-Toshio


pgpSh6GME5F7L.pgp
Description: PGP signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test