Xavier Parizet a écrit :
> Hi list,
>
> I eard some (long) time ago that portage is not compatible with python 2.7, so i
> masked it (python) in /etc/portage/package.mask. What i would like to know now
> is is portage now compatible with this version of python ? Or if not, where can
> i follow the status of this compatibility ? I looked on b.g.o but didn't find
> anything related to this.
>
> Many thanks in advance.
>
Sorry but instead of python 2.7 (which does not exists), i was talking about
python 3 support in portage. Is it safe to remove earlier version of python to
only keep version 3 ?
I eard some (long) time ago that portage is not compatible with python 2.7, so i
masked it (python) in /etc/portage/package.mask. What i would like to know now
is is portage now compatible with this version of python ? Or if not, where can
i follow the status of this compatibility ? I looked on b.g.o but didn't find
anything related to this.
Many thanks in advance.
Sorry but instead of python 2.7 (which does not exists), i was talking about
python 3 support in portage. Is it safe to remove earlier version of python to
only keep version 3 ?
Thanks and sorry for the mistake.
Out of curiosity I tried this a while back. Portage had been updated a
couple time since then but at the time, portage was not happy at all. I
seem to recall some other programs not being happy either but I can't
recall which ones.
Since it is keyworded and masked. I would leave it alone.
Dale
:-) :-)
12-07-2009, 11:18 AM
Alan McKinnon
On Monday 07 December 2009 13:11:52 Xavier Parizet wrote:
> Xavier Parizet a écrit :
> > Hi list,
> >
> > I eard some (long) time ago that portage is not compatible with python
> > 2.7, so i masked it (python) in /etc/portage/package.mask. What i would
> > like to know now is is portage now compatible with this version of python
> > ? Or if not, where can i follow the status of this compatibility ? I
> > looked on b.g.o but didn't find anything related to this.
> >
> > Many thanks in advance.
>
> Sorry but instead of python 2.7 (which does not exists), i was talking
> about python 3 support in portage. Is it safe to remove earlier version of
> python to only keep version 3 ?
No.
Google will tell you why.
--
alan dot mckinnon at gmail dot com
12-07-2009, 11:38 AM
Albert Hopkins
On Mon, 2009-12-07 at 12:11 +0100, Xavier Parizet wrote:
> Sorry but instead of python 2.7 (which does not exists), i was talking
> about
> python 3 support in portage. Is it safe to remove earlier version of
> python to
> only keep version 3 ?
No. When you installed python3 it pretty much tells you *not* to do
this. You get a big fat WARNING:
WARNING!
Many Python modules haven't been ported yet to Python 3.*.
Python 3 hasn't been activated and Python wrapper is still
configured to use Python 2. You can manually activate Python 3.1
using `eselect python set python3.1`. It is recommended to
currently have Python wrapper configured to use Python 2. Having
Python wrapper configured to use Python 3 is unsupported.
12-07-2009, 01:11 PM
Gour
Hiya,
Please if you can remove xulrunner-xpcom package
(http://aur.archlinux.org/packages.php?ID=28526) which is now obsolete
'cause the same functionality is provided by official xulrunner
package.
On Mon, Dec 7, 2009 at 11:11 AM, Gour <gour@gour-nitai.com> wrote:
> Hiya,
>
> Please if you can remove xulrunner-xpcom package
> (http://aur.archlinux.org/packages.php?ID=28526) which is now obsolete
> 'cause the same functionality is provided by official xulrunner
> package.
>
>
> Sincerely,
> Gour
Done
--
Angel Velásquez
angvp @ irc.freenode.net
Arch Linux Trusted User
Linux Counter: #359909
http://www.angvp.com
12-07-2009, 02:45 PM
Mike Snitzer
On Mon, Dec 07 2009 at 9:01am -0500,
Mike Snitzer <snitzer@redhat.com> wrote:
> On Mon, Dec 07 2009 at 6:22am -0500,
> Mikulas Patocka <mpatocka@redhat.com> wrote:
>
> >
> >
> > On Sun, 6 Dec 2009, Mike Snitzer wrote:
> >
> > > On Sat, Dec 05 2009 at 9:01pm -0500,
> > > Mikulas Patocka <mpatocka@redhat.com> wrote:
> > >
> > > > On Sat, 5 Dec 2009, Mike Snitzer wrote:
> > > >
> > > > > Switch stop_merge() from using a busy loop to a completion event.
> > > > >
> > > > > stop_merge() now requests merging be shutdown using the
> > > > > 'merge_completion' pointer (instead of the 'merge_shutdown' flag). This
> > > > > is accomplished by testing if 'merge_completion' is not NULL in
> > > > > snapshot_merge_process(). stop_merge() allocates its completion on the
> > > > > stack and assigns it to the 'merge_completion' pointer in the snapshot.
> > > > > 'merge_completion' is protected by the snapshot's lock.
> > > > >
> > > > > Also changed the 'merge_running' flag from int to atomic_t.
> > > >
> > > > No, there's a bug:
> > > >
> > > > > static void stop_merge(struct dm_snapshot *s)
> > > > > {
> > > > > - while (s->merge_running) {
> > > > > - s->merge_shutdown = 1;
> > > > > - msleep(1);
> > > > > + DECLARE_COMPLETION_ONSTACK(merge_stopped);
> > > > > + if (atomic_read(&s->merge_running)) {
> > > >
> > > > --- if the merge stops exactly at this point (because it gets finished or
> > > > because of an i/o error), we are waiting for a completion that will be
> > > > never signalled.
> > >
> > > Yes, valid point. But for this rare corner case we could just use
> > > wait_for_completion_timeout() with a fairly large timeout; like 30 sec?
> > > That actually isn't a great option (racey)...
> > >
> > > How about if the 'shut:' code paths also checked for s->merge_completion
> > > and complete() if it is not NULL? Which means that check and related
> > > complete() code would become a function.
> > >
> > > > > + down_write(&s->lock);
> > > > > + s->merge_completion = &merge_stopped;
> > > > > + up_write(&s->lock);
> > > > > + wait_for_completion(&merge_stopped);
> > > > > }
> > > > > - s->merge_shutdown = 0;
> > > > > }
> > > > >
> > > > > /*
> > > >
> > > > For Alasdair: do you get the problem? If I write it with msleep()
> > > > correctly, you keep on complaining how unclean it is --- if it is written
> > > > with completions and it is wrong (because they are just harder to use
> > > > correctly than simple variables and msleep), you tend to support it. Now
> > > > you see in practice how complex constructs tend to trigger bugs.
> > > >
> > > > Mike: I thought that the completion would be in struct dm_snapshot. But
> > > > maybe, try it with wait_on_bit / wake_up_bit / test_bit / set_bit etc., it
> > > > may be easier than completions.
> > >
> > > I can look at it; but I think using a completion can work.
> > >
> > > Mike
> >
> > Here it is with bits:
>
> OK, looks good; especially in that we can reuse 'bits' for other things
> as needed.
>
> Acked-by: Mike Snitzer <snitzer@redhat.com>
Here is a refreshed patch that applies cleanly ontop of the
'merge_failed' patch. I've added it to my quilt tree that is here:
http://people.redhat.com/msnitzer/patches/snapshot-merge/kernel/2.6.33/
---
dm snapshot: eliminate busy waiting when stopping merge
stop_merge() now requests merging be shutdown by setting the
'SHUTDOWN_MERGE' bit. stop_merge() then waits on the 'SNAPSHOT_RUNNING'
bit to be cleared rather tahn busy waiting.
- /* Merge operation failed if this is set */
- int merge_failed;
+ /* Wait for events based on state bits */
+ unsigned long bits;
/* Merge operation is in progress */
- int merge_running;
+#define MERGE_RUNNING 0
/* It is requested to shut down merging */
/* Cleared back to 0 when the merging is stopped */
- int merge_shutdown;
+#define SHUTDOWN_MERGE 1
+
+ /* Merge operation failed if this is set */
+ int merge_failed;
/* Merging this area --- block any writes */
chunk_t merge_write_interlock;
@@ -776,8 +779,8 @@ static void snapshot_merge_process(struc
struct dm_io_region src, dest;
sector_t io_size;
- BUG_ON(!s->merge_running);
- if (s->merge_shutdown)
+ BUG_ON(!test_bit(MERGE_RUNNING, &s->bits));
+ if (unlikely(test_bit(SHUTDOWN_MERGE, &s->bits)))
goto shut;
if (!s->valid) {
@@ -849,7 +852,9 @@ test_again:
return;
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
12-08-2009, 09:05 PM
Wayne
-------- Original Message --------
Subject: Re: Alt key not working
Date: Tue, 8 Dec 2009 22:25:41 +0100
From: roberto <roberto03@gmail.com>
To: Wayne <linuxtwo@gmail.com>
References:
<4bcde3e10912080934t4b85e591j23f729a6658d45d8@mail .gmail.com>
<4B1E9851.2010405@gmail.com>
On Tue, Dec 8, 2009 at 7:17 PM, Wayne <linuxtwo@gmail.com> wrote:
roberto wrote:
hello, i use debian 5.0 and recently i ran into the following strange
malfunctioning:
i do not know why, but the Alt key of the keyboard suddenly stopped
working
is there any way to get an idea of what is going on ?
thank you very much in advance
Have you checked out the console-tools package?
The showkey program for instance.
yes and i get
~$ showkey
Couldnt get a file descriptor referring to the console
From your reply it is not clear, to me anyway, if you do have the
console-tools package installed. The showkeys program is in that
package. If you need to figure out how/what it is for, I suggest you
try reading the man page.
Please to NOT send personal mail to people who attempt to help you.
Responding to the list is the normal way to get help for yourself and
other members of D-U.
Wayne
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
12-09-2009, 02:54 AM
Tony Nelson
On 09-12-08 17:05:39, Wayne wrote:
>
> From: roberto <roberto03@gmail.com>
...
> On Tue, Dec 8, 2009 at 7:17 PM, Wayne <linuxtwo@gmail.com> wrote:
...
> > Have you checked out the console-tools package?
> >
> > The showkey program for instance.
>
> yes and i get
> ~$ showkey
> Couldnt get a file descriptor referring to the console
>
> From your reply it is not clear, to me anyway, if you do have the
> console-tools package installed. The showkeys program is in that
> package. If you need to figure out how/what it is for, I suggest you
> try reading the man page.
I got the same message (on Fedora 12) when running as a normal user.
It works when run as root.
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
12-09-2009, 11:47 AM
Pierre Schmitz
Hi devs,
I did have a closer look at chromium recently and it did improve a lot. Even
though it's called "beta" it is really usable and feature complete.
There is quite a high demand for it (the binary version in AUR has neraly 800
votes). I would like to make a peoper package for it and provide that in our
repo.
The AUR packages are either svn trunk builds or repackaged ubuntu debs with
ugly symlinks to libs with other so names.
My idea is to build a tar out of their svn tag and build a clean package with
that.
What do you think? (it's about chromium btw. and not Chrome which is Google's
build with some "extras")
--
Pierre Schmitz, https://users.archlinux.de/~pierre
