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
portag
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 u
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
fu
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
Perhaps,
The problem here is that the paludis team appear to have a conflict of
interests due to their previous and/or current association with Gentoo.
I know they've mentioned personal grudges, so despite not knowing who
these people are, I'm going to assume they have a history with Gento
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 inf
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 securit
-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 signed
-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 de
-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 SIGNA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tiziano Müller wrote:
| Hi everyone
|
| What do you think of creating a new 'virtualization' project or herd/team?
Sounds like a good idea, there seem to be enough packages to warrant it.
~ Especially if you're finding shared packages and space for
-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, bu
-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 --as-nee
-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 must
-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
Ciaran McCreesh wrote:
| And in amongst all of this, if you fight really really hard, you might,
| after several months and a whole lot of people trying to kill you,
| eventually get agreement upon some very minor technical point that's
| necessary to
-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 for
-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 v
-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
> ha
-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
> preferen
-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 instan
-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
> metadata
-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 mentio
-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 o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
# Mike Auty (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 SIGNATURE-
Ve
-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
com
-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
chang
-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 wo
-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 t
-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, vmware-mo
-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 re
-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 https://bug
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 the
On 10/03/18 14:52, Pacho Ramos wrote:
> This packages are now up for grabs:
> ...
> dev-python/mypy
> ...
I can look after this one if nobody else wants it?
Mike 5:)
signature.asc
Description: OpenPGP digital signature
Hiya,
I'm trying to update/package up mypy for the main tree which, whilst it
provides a release tarball, relies upon a data library (typeshed) which
does not provide releases. The recommended method of installation by
upstream is to use git submodules (which the ebuild will do happily),
but repo
Making typeshed its own package doesn't help because it's installed
under /usr/share/mypy/typeshed, not /usr/share/typeshed so it really is
part of mypy (for now). So I'll see how this goes and listen for
feedback...
Mike 5:)
On 11/03/18 18:05, Mike Auty wrote:
> Hiya,
>
&g
# 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
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, Mic
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 usernam
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
-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
O
-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 fo
-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; a
-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
> wrote:
>
>> On 9 August 2013 21:57, Michał Górny wrote:
>>> This one is *so special* just because we have a few folks
>>> which really have nothing useful to d
-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 o
-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
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. Inclu
-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 ca
-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 rainbo
-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 pu
-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. S
-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 (GNU/Linux
-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 vanill
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 de
-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 goi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
It was my understanding,
That minor QA violations like this, which affected the sanity of the
tree, were simply added as checks to repoman - which all committing devs
should use. This would (over time) stop new ebuilds of the broken form
appea
-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
ksz
-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 SIGNATUR
-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 Gentoo.
-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 in
-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 befo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John R. Graham wrote:
> But, hasn't anyone realized that bash is _broken_ if this file doesn't
> exist? Quoting from the upstream-provided man page, "When an
> interactive shell that is not a login shell is started, bash reads and
> executes commands
-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 "~/.bash
-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 t
-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 dif
-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 t
-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
confi
-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
-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 optio
-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 hal
-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 (al
-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 w
-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 gobject-
-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 i
-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 executi
-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,
Hiya,
On 13/09/2018 01:23, Chí-Thanh Christopher Nguyễn wrote:
> Installation will proceed, but the user will get a big fat warning that
> the sys-fs/zfs package is potentially broken.
This seems like a sure-fire way to make users paranoid and/or
desensitized? People will learn to ignore warning
I'd like to claim:
> app-crypt/ssdeep
and
> app-crypt/xca
I'll add my information to the metadata.xml for them...
Mike 5:)
signature.asc
Description: OpenPGP digital signature
1 - 100 of 105 matches
Mail list logo
