Well,
I think a lot of what I've been thinking recently has already been said
by Daniel. I'm actually in the middle of being inducted and I'm just
concerned that I'm going to get extra responsibility without any real
positive aspects for me. I don't really *want* access to check into
I'd prefer,
The first option (two yes/nos and a list) since it seems cleaner and
more obvious. The only issue that I could see is where someone might
want a service started by hotplug rather than coldplug or vice-versa. I
honestly don't know anywhere near enough about the difference (up
Roy,
I think the complaint is the automatic loading of modules by udev.
Seemingly in the udev Changelog this is referred to as add udevtrigger
to request events for coldplug, whereas it seems you're using coldplug
to refer to the automatic starting of services. Is there another name
for
Forgive me,
I'm a little new at this and I really don't want to get involved, but
since my inbox has seen nothing but this for the past day or two, I'm
going to ask a few questions I'm interested in the answers to...
First and foremost is, will adding this to the tree be used for
Stephen Bennett wrote:
The
question is simply one of whether I can add a top-level paludis profile
without people complaining overmuch, or whether I have to go through
the arch teams and make sub-profiles in 4 different places under
default-linux/.
That implies it's going to be added to the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everybody,
The Gentoo vmware team have been developing new ebuilds for
vmware-workstation, vmware-player and vmware-server (and
vmware-server-console), to help ease the maintenance of the shared
modules and shared patches between these products.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/08/13 11:38, Samuli Suominen wrote:
i'm not volunteering but I never really got why our GNOME
maintainers insisted on staying with it instead of going with the
distribution after it was clear logind is a dead end on non-systemd
systemd
Ok,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/08/13 22:06, Pacho Ramos wrote:
Anyway, are you sure openRC is better than systemd for desktop
systems (for deserving the effort to keep maintaining consolekit,
that is currently orphan, cgroups stuff and any other things I am
probably
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/08/13 00:19, Greg KH wrote:
Become upstream developers and create fixes to remove the
dependancy either by working on openrc features to emulate the same
things that systemd has that GNOME requires, or split things out of
GNOME so that it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/08/13 10:35, Tom Wijsman wrote:
Listening comes at a price; you can't listen to everyone at the
same time, all you will hear is noise because all the voices clash.
So, you've got to listen to a selective bit of users and satisfy
them;
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/08/13 21:32, Tom Wijsman wrote:
On Sat, 10 Aug 2013 03:11:55 +0800 Ben de Groot yng...@gentoo.org
wrote:
On 9 August 2013 21:57, Michał Górny mgo...@gentoo.org wrote:
This one is *so special* just because we have a few folks
which really
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/08/13 23:42, Wulf C. Krueger wrote:
On 09.08.2013 02:26, Mike Auty wrote:
I could be a KDE developer, or a Gentoo documenter, or work on
mplayer. All those people are open source contributors and
necessary ones, but that doesn't mean
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/08/13 00:45, Canek Peláez Valdés wrote:
They thought deeply about the changes that are being made to the
desktop, and they discussed it and reached a consensus about what
the direction of the project is; you can usually read about in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Petteri Räty wrote:
3) EAPI in locked down place in the ebuild
c) .ebuild in current directory
- needs one year wait
I'm all for 1 or 3c, because we're not in any rush.
I don't see why there's such an immediate need to make as drastic
changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tomáš Chvátal wrote:
I am throwing in full new eclass [1] and its diff [2].
Errr, maybe it's my eyes, but it looks as though the new eclass isn't
the same as the existing eclass with the diff applied (for instance,
git_src_prepare doesn't get called
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Faulhammer wrote:
What else? As some of you might foresee, this can be as hard as a
major GCC stabilisation, so it must be well-planned and organised.
Depends on which version of openrc gets stabilized in the process.
We're currently
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan wrote:
Or should I file the bugs? It seems no one else has and maybe the
maintainers don't have the config for what they're maintaining, or
otherwise don't see the warnings.
I'm aware of the dm-crypt issue and will try and spend some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Everybody,
Last week I stepped down from the vmware herd, and since I was the only
member left, there are no more maintainers for the vmware packages in
the tree. The current packages are vmware-workstation, vmware-server,
vmware-player,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Roy Marples wrote:
Attached is the new conf.d/net sample.
Sorry, I missed those. Did lists.g.o remove them, or were they not
attached?
As such, a side project I've started is a new ifconfig tool
[1] to handle everything from vlans, to bridging,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hiya guys,
One of the packages I maintain (nipper) has recently undergone a change
of license, from being GPLed to a new license that whilst mostly being
commercial features a non-commercial/personal use element.
Due to the new license (and the no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
The website stills says GPL v3:
http://nipper.titania.co.uk/licensing.php
Yep, the website's going to be updated for version 1.0 (with the license
change).
...
I can't really comment on a lot of this, unfortunately.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Казанков Александр Владимирович wrote:
Hello.
Hi,
Could you please file all this information (and the output from emerge
- --info at https://bugs.gentoo.org/. This mailing list is for technical
discussions, whereas the bug tracker at
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
William Hubbs wrote:
I agree here. The eclass should check /proc/config.gz.
Also, another reason to use the eclass is it respects KBUILD_OUTPUT if
it is set.
- From the indenting I can't tell if you wrote this or not, however, we
need to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
It does NOT check /proc/config.gz presently. The original logic against
not checking /proc was that we were targeting the kernel being built,
but that's moot given the use of `uname -r` in OUTPUT_DIR.
I might be reading the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
FYI:
get_running_version is used in one single ebuild, in the entire tree:
sys-fs/evms/evms-2.5.5-r10.ebuild
And there it's only for a warning.
Ok, I was just suggesting that if there was an intention to implement
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
The existing state is:
- Force the user to install sources
Our choices are:
- `uname -r` output.
- Create an override environment variable for all the checks.
/proc/config.gz comes back here again, in that, we can use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
Yes, a warning with using /proc/config.gz.
I missed a bit for the config option.
If there is NO source of the config data, what do we do?
Error out or more warnings?
Well, if we can't determine whether a config option's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
If you feel like reviewing ~140 packages and filing bugs for them, I
won't stop you. But I'm just going to go and fix the ones that seem
simple enough to me, and only file bugs for the complex ones.
Ok, I'll do what I can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok,
Here's the list of ebuilds that feature a CONFIG_CHECK, and which ones
I've been through to check for either NONEED (already using ~option),
MODULE (builds a module so may really want to bomb out), and FIXED
(packages which I've fixed).
About
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Patrick Lauer wrote:
At least I'm trying to keep these
packages alive, which noone else seems to do.
If you spot that a new version is available, you're more than welcome to
post a version bump bug assigned to the appropriate herd and developer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hiya William,
Sudo can be used to restrict access, so that only certain programs can
be run using it. It asks for your password rather than the user you're
trying to login to (unlike su). It also helps maintain a more accurate
audit trail
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22/06/10 15:33, Arun Raghavan wrote:
Why not just gintrospection?
I still think introspection is easier to grok. It's unlikely that
it's going to be used in a completely different sense by other
packages in the future, so let's stick with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22/06/10 18:11, Arun Raghavan wrote:
It is not a GNOME-only flag.
A general introspection flag may not be, but this isn't a general
introspection flag, this is specific to gobject and the suggestions try
to clarify that. People who want
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John R. Graham wrote:
Mike, I agree. But, the file that _must_ exist isn't ~/.bashrc but
~/.bash_profile. That's where the that particular bit of
man-page-defined behavior is implemented. If ~/.bash_profile doesn't
exist, then ~/.bashrc won't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry to see you leave,
I can maintain scapy if no one else wants to?
Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
iD8DBQFHqglzu7rWomwgFXoRAismAJ4+4D50v0k6VSRfEfRV4mMiBP9QHACeLHJB
1IYpKEqzWFsdiFYXG7IJyhc=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Jo,
It appears that bug 177978 answers your question. Apparently libiptc
wasn't meant to be a public interface and is intended to be removed from
the iptables pacakge[2]. Hope this helps answer your question. Please
do have a good hunt
Petteri Räty wrote:
Defining required amount of activity for ebuild devs. I would like us to
raise the required amount of activity for ebuild devs.
Given that the low number of developers is ranked as our number one
problem in Donnie's informal survey[1], taking any kind of action
against
Petteri Räty wrote:
If you can't manage weekly commits, you can't respond to security issues
either.
I can see your point, I was more thinking about developers who have
maybe one or two small packages that don't have many version bumps or
bugs. They may be entirely able to respond to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Petteri Räty wrote:
| Yeah, you only need access to one ebuild to do whatever you want to
| user's systems.
Perhaps then we should direct more of our efforts towards the GPG
package signing system, so that when a dev becomes a libability, their
keys
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
|
| Signing offers no protection against a malicious developer.
|
I had envisaged a system whereby when the tree was synced, as was some
kind of master signed list of all acceptable dev-keys. Every package
would also be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
William L. Thomson Jr. wrote:
| It's about quality not quantity maybe?
It's about both, and getting the balance right is effectively what this
boils down to (as do many discussions on -dev). There's those devs who
want high levels of QA and those
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Alon Bar-Lev wrote:
| If we know there may be a future problem, why make the next *VALID*
| addition perform extra work?
I think the reasoning is that whilst there may be a future problem,
there currently isn't. If it gets changed to gnome-keyring,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hiya Duncs,
Sorry to hear your time constraints have gotten the better of you
finally. Best of luck with well-typed, I hope it proves interesting and
that you bring much Haskelly joy to the world... 5;)
Mike 5:)
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tiziano Müller wrote:
| That's true. How about having a virtualization project which takes care of
| the common part, the docs and the coordination (if any) and have separate
| herds for larger subprojects?
Sounds ideal. 5:)
Mike 5:)
-BEGIN
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
| The purpose of this is to keep the system operational after library
| upgrades until all affected packages could be rebuilt and to simplify
| the process, not to avoid the rebuilds.
I couldn't find it mentioned in your email,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Volkov wrote:
| Is there any reason why --as-needed is not enabled by default?
There's still about 18 open bugs on the tracker[1] for it. You can see
how many problems it had been causing by the huge number of blocking bugs.
I've been using
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ulrich Mueller wrote:
| But maybe Emacs is an uncommon application, or I am looking for the
| wrong things? Could one of the experts please shed some light on this?
I think you're looking for the wrong things. I'm not an expert, but I
think
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ciaran McCreesh wrote:
| No, it results in a new open() on a file that's elsewhere on disk, which
| results in two new seeks. You get about fifty seeks per second.
The speed issues aren't really a concern, since the GLEP suggests that
the ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Kelly wrote:
| Wrong.
Thanks for that. I'm gonna assume you meant I think you're wrong.
| Sure, because of how the algorithm works, people could potentially do
| both, but the GLEP makes it pretty clear that they shouldn't.
It doesn't just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It seems,
Slightly like an abuse of the RESTRICT variable. I had thought that
RESTRICT was generally for when a normal ebuild needed a feature turning
off (such as mirroring, strict checking and hopefully one day ccache).
5:) Overloading it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Zac Medico wrote:
| Honestly I don't care what the existing scheme is.
Fair enough, I don't maintain the code or have to deal with the
complaints. It seems a waste to abandon an existing scheme though.
Particularly since RESTRICT is an odd name
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Buchholz wrote:
How is using the eclass better for bandwidth usage? It won't allow for
mirroring, and all users would have to checkout the repository from one
place. Furthermore, you cannot have (signed) Manifests that allow
integrity
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Buchholz wrote:
How is using the eclass better for bandwidth usage? It won't allow for
mirroring, and all users would have to checkout the repository from one
place. Furthermore, you cannot have (signed) Manifests that allow
integrity
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Santiago M. Mola wrote:
If you're just dealing with the default phases, it's not too hard to
say in advance the exact command that will be executed.
If that's the case, why go so far as to define three new variables and
potentially put them out in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marius Mauch wrote:
Maybe the best solution is to drop the non-prefixed versions of 'world'
and 'system' completely
Deprecating the old syntax sounds like a sensible action to get people
shifted onto the new system. I imagine it would work
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeroen Roovers wrote:
I spotted that too but didn't remember putting it in black and white. :)
The order (first maintainer as assignee or first maintainer/herd as
assignee) is open to discussion and I think this is the proper forum to
have that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Buchholz wrote:
Accepting the fact that different teams have different preferences, we
need to find a solution for them to set theirs individually. This could
either be the order of elements in metadata.xml (and would set the
preference
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Buchholz wrote:
* Order in metadata.xml is what dictates assignee, i.e.: The first herd
or maintainer listed in the metadata.xml of the first CAT or CAT/PN
is who is assignee, all other follow as CC.
Great work, just wanted to double
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan wrote:
Amarok2 - dev-db/mysql-community - ld: /usr/lib64/mysql/libmysqld.a
(client.o): relocation R_X86_64_32S against `client_errors' can not be
used when making a shared object; recompile with -fPIC
Well, I fixed this individual
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robin H. Johnson wrote:
Neither set of rules is ideal. Ordering makes a lot of sense when you
just read it. Consider metadata with multiple maintainers and multiple
herds. Either you have to start assigning explicitly (requires editing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I realize it might be a bit obvious to us, but from reading it people
might wonder how they're supposed to carry out installs now. When the
notice finally goes out, it might be worth mentioning that just the
LiveCDs are no longer supported, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hiya Anthony,
First off, it certainly sounds interesting and making it more
accessible (simple ebuild setup and so on) seems like a good plan even
if it doesn't get picked up officially. The best way to start
development would probably be an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
# Mike Auty ike...@gentoo.org (1 Feb 2009)
# Masked for removal in 30 days. Old and unmaintained.
# Vmware herd has no access to the product, and it's
# for a very old version. See bug 143232.
app-emulation/vmware-esx-console
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Petteri Räty wrote:
So until we have a decision on what the replacement will be I
don't see a need to remove current prepalldocs usage but any new usage
must be avoided.
If it's simply discouraged, perhaps a repoman check, and some people to
come
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hiya Alon!
Congratulations, your bug contributions so far have been supremely
helpful, I'm really glad to see you made the leap to developer. Welcome
aboard! 5:)
Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm not certain,
That turning vanilla-sources into linux-sources is wise, since it would
then follow that gentoo-sources become gentoo-linux-sources, and so on
for all the other linux variants. Since everybody knows and understands
what
Or perhaps,
Something a little more explicit might work? In instances such as the
ifconfig lines, it's to create eth0 aliases (such as eth0:0), so perhaps
that could look like:
ifconfig_eth0:0 = 10.1.1.1 netmask 255.255.255.0
ifconfig_eth0:1 = 10.1.1.2 netmask 255.255.255.0
For
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan wrote:
However, now that PMS is finally about to provide what should be a
definitive description of current generation package behavior, with the
announced intention to update this with new versions into the future as
required, the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Duncan wrote:
The point being, however, that all this quarreling about official
package managers doesn't /really/ have to happen. [...]
I just don't see why so many are spending
so much time arguing over it, when regardless, people are going to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hiya,
Reading over the discussion on lkml, it appears that it only affects
x86_64 systems...
Mike 5:)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.3 (GNU/Linux)
iD8DBQFGQQlpu7rWomwgFXoRAhzPAJ94Dcg/S0a6dtHodXRyPRgRT4CS0gCdHSW2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It can also,
Be used by kismet, but it's not clear whether there are strong bindings
there, or if espeak could easily be substituted using kismet.conf.
Dunno if that's useful or not, but there you go...
Mike 5:)
-BEGIN PGP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tobias,
As a mostly under-spoken developer, I'd like to say that there are many
other developers in Gentoo than just those seen regularly on -dev. We
also add ebuilds to the tree, but tend to be content minding our own
little corner of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kent Fredric wrote:
Ok, I've re-thought some of my ideas and tried to come up with a more
concise explanation
with some practical example syntax. The basic concept of 'check' was
'this will work even if the package aint installed yet' and info
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vlastimil Babka wrote:
I think he wants to do exactly that, but having the code needed for this
right in the ebuild, so it can benefit from varibles like PV and
versionator eclass for converting PV to e.g. CVS tags... I think it's
quite elegant
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dirk,
Could you please describe the problem you faced? From the detail you
gave, it sounds as though you might not have moved /etc/conf.d/cryptfs
to /etc/conf.d/dmcrypt. There's currently several ewarn lines saying
that this must be done
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry I'm a bit late to the thread,
Just to add that empathy preserves libemapthy in this manner too.
On 05/07/10 17:40, Gilles Dartiguelongue wrote:
1. How is it different than preserved-libs feature from
portage-2.2 ? The issue
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15/07/10 14:57, Maciej Mrozowski wrote:
And what about using portage 2.2 and be done with it. I don't see the point
in
reinventing the wheel yet again.
I'm using portage-2.2 and have been since it first came out. I find the
@set notation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'd thought that the new eclass was designed to ensure that if you asked
for USE=python it was built for as many different python ABIs as was
installed on your system (so python2 and python3 if they're both
installed). I believe it's possible to ask
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/08/10 18:26, Olivier Crête wrote:
Other distributions are going one step further and are going for
shell-free boot. We should follow that lead.
Why? Presumably they're doing it by writing programs that do their own
parsing and executing,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It should be possible to still maintain this distinction, something like:
Version bump. Added feature foo.
- --
Feature foo required a complete rewrite of src_install.
And then the ChangeLog generation can happen separately. The problem
with this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/11/10 02:40, Donnie Berkholz wrote:
I read it more closely and realized I was a little confused by the way
you listed all the bullet points mixing together benefits and problems.
So I'll try again: if you really want to do this change, you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi there,
I'm updating the app-crypt/ophcrack-tables package to include the new
tables available from their site. These are basically just additional
data packages that can be useful with the app-crypt/ophcrack package,
but they're very large.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hiya,
First off, thanks everybody for the suggestions. It seems like people
aren't keen to mirror the large tables on our mirrors, but no one's
mentioned a reason for not doing so. Is there an infra reason behind
that or did everyone just take my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16/10/13 12:01, Duncan wrote:
If it's a core requirement, no problem. But the further from core
requirement it gets the more sensitive infra seems to be about
non- trivial space requirements, and any way you look at it, 30
gigs of rainbow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hiya,
On 16/10/13 12:54, Francesco R. wrote:
Il 16/10/2013 11:15, Mike Auty ha scritto: Add a bash script that
can download all the files and mention it in postinst. the script
will download all the files in current directory and put them
Yeah,
Sorry about the double posting, patrick told me about a gmail feature
that means you never see your own posts...
I agree that the updates should only affect that individual tree.
Whilst I can imagine cases where a move in the main tree should affect
overlay trees (such as
Ok,
Well, what if instead we were to try and treat the overlay trees as
exactly that, overlays. So the moves were used from the lowest layer
(ie the main tree) unless a higher up layer overrode them, could that
work? It would mean effectively that the overlay moves were global, but
I guess
Jim,
I opened bug 158632, so that's worth looking at. It also points to a
post on the forums about the problem. I can't add much to the
discussion myself, just that it affected two of my machines differently
which I found rather odd (one has difficulty with all versions of mpc,
the other
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sorry,
I lost my notes from when I last looked these over several months ago,
and only just found them again. I haven't copied this to [EMAIL PROTECTED], so
let me know if I should do that. I just had a quick couple of things I
was thinking
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Emma Strubell wrote:
There must be a faster python pickler out there, though, any
recommendations?
Right off the bat, you might try cPickle. It should work identically,
just faster. Also you can try importing psyco, if it's present it will
try
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hiya,
On 06/02/15 11:49, Ben de Groot wrote:
Since we introduced the libav useflag, we have now a way to
finally make mpv-0.7* (using the upstream recommended ffmpeg as
default) visible to ~arch users, without the need to unmask it.
Users who
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hiya,
On 06/02/15 08:48, Duncan wrote:
Daniel Campbell posted on Thu, 05 Feb 2015 22:55:05 -0800 as
excerpted:
As a user and prospective developer, why? Transparency is
important to open communities like Gentoo's, and reading the
discussions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hiya,
On 07/02/15 05:16, Ben de Groot wrote:
I discussed this beforehand with said developer on IRC.
Ok, that wasn't clear from the commit message.
Do you think a news item to explain this situation and giving
explicit instructions for users who
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Whilst the default *is* still in place (and particularly after the
recent news article detailing that users should be using libav), could
we please keep commits like the following until *after* we've made an
agreed upon decision please?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hiya,
I also experienced this (on 2a01:488:67:1000:b01c:3277:0:1). It will
also prevent portage from resyncing because it assumes the portage
tree is under revision control (when there's just git directories, no
actual data). It looks like infra
Sorry for the spam!
Apparently the sender of list mails isn't the actual author of the
message. 5:S
Mike 5:)
On 21/11/16 09:27, Mike Auty wrote:
> Hiya,
>
> It wasn't clear how to get added to the github team in the first place,
> but I've got the same username on github as
Hiya,
It wasn't clear how to get added to the github team in the first place,
but I've got the same username on github as I use for my gentoo handle
(ikelos). I've also now got my ike...@gentoo.org GPG key verified on
there if you're after confirmation. Thanks!
Mike 5:)
On 21/11/16 09:01,
Hiya Jan,
The following snippet from Ingo is correct:
> So, you want to hear something constructive? Your best option is to
> just decompress that stuff on your system. (Gentoo is famous for
> its excessive configurability - maybe there is even an option?)
We are both famous for our excessive
# Mike Auty (22 Jun 2018)
# Not maintained upstream, at least one bug and three upstream bugs
# Removal in 30 days. Bug #658264
dev-vcs/giggle
Mike 5:)
signature.asc
Description: OpenPGP digital signature
On 08/02/18 20:55, Mike Gilbert wrote:
> However, there are plenty of examples of commands that normal users
> may run from sbin.
Hiya,
I'm not really for or against the idea, but whenever the justification
for something is "there are plenty of examples" it's really helpful to
have a number of
1 - 100 of 105 matches
Mail list logo
