merge commits on master. That
> would force everyone to rebase their work on current master before
> they commit to master which would make the history clean.
What would git signing work with rebased commits? Would all of them
have to be signed once again?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
On Thu, 31 May 2012 15:58:43 -0400
Rich Freeman wrote:
> On Thu, May 31, 2012 at 3:33 PM, Michał Górny
> wrote:
> > What would git signing work with rebased commits? Would all of them
> > have to be signed once again?
> >
>
> The whole point of rebasing is t
o a git show on
> a merge commit, you get nothing, so there is no way to see what
> actually changed in that commit.
Or you use a graphical tool which shows the whole merge history and you
see the exact changes happening rather than some blob with 'do foo, do
bar, and some baz too'.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
On Thu, 31 May 2012 16:27:48 -0400
Michael Orlitzky wrote:
> On 05/31/12 16:09, Michał Górny wrote:
> > On Thu, 31 May 2012 15:58:43 -0400
> > Rich Freeman wrote:
> >
> >> On Thu, May 31, 2012 at 3:33 PM, Michał Górny
> >> wrote:
> >>> What
y.
I don't think that 'not necessarily' makes any difference here. Maybe
in our particular case this is not as likely as with regular source
code tree but while rebasing you can hit conflicts. And then files
start to change...
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
est file changing every
> sign )
Yes, it's no worse so we're practically considering implementing a very
complex mechanism for no real benefit.
As I see it, as good would be only requiring some kind of 'top-level'
commits to be signed. For example, if one does merge a bra
7;t be able to read exactly
one result at a time but is it actually useful?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
understand this part. This keeps the pipe open for reading
which obviously causes it to lose data. If you open it, you need to
read all that is there and then close.
And writers are supposed to be blocked. They are forked and just write
when done, so there's no problem with keeping them
ome to the point where git will be more
efficient than rsync. Or maybe it would be already?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
I
> > said, that's handwavey guesses.
> No, the switch to git will NOT help users, it isn't more efficient.
>
> They will still be best served by rsync, for a couple of reasons:
> 1. metadata cache is NOT available in Git.
I means using separate proto for metadata, not
changed,
in a packed manner.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
One could set S to work on a subtree of the tarball rather than
the whole tarball. Considering that, it's probably better to use
${WORKDIR}/${P} rather than ${S}.
Fixes: https://bugs.gentoo.org/show_bug.cgi?id=419479
---
gx86/eclass/vcs-snapshot.eclass |5 +++--
1 file changed, 3 insertions(+
On Mon, 04 Jun 2012 16:20:02 +0200
hasufell wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/04/2012 11:59 AM, Michał Górny wrote:
> > One could set S to work on a subtree of the tarball rather than the
> > whole tarball. Considering that, it&
t it if you can get more approval for that
change. Or else we should consider jumping with the eclass to -r1 while
it isn't widespread too much.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
good solution but the server-side hooks could
also verify the tree state before applying new commits.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
x27; to me. I'd rather see those few
conflicts and fix them once in a while rather than having to lookup
multiple package.mask files with entries split in a semi-random manner.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
On Mon, 04 Jun 2012 22:47:33 +0200
hasufell wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/04/2012 10:06 PM, Michał Górny wrote:
> > On Mon, 04 Jun 2012 21:26:00 +0200 hasufell
> > wrote:
> >
> >> But minetest in sunrise for example
This includes gtkdocize, gnome-doc-prepare & glib-gettextize.
---
gx86/eclass/autotools.eclass | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/gx86/eclass/autotools.eclass b/gx86/eclass/autotools.eclass
index 2d165e0..30f2ac5 100644
--- a/gx86/eclas
on: 1.395; previous revision: 1.394
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
they would not
relocate when support for that particular format is added.
By the way, the credit for the overall idea goes to hasufell.
--
Best regards,
Michał Górny
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLAS
e fact
that .tar* is the format preferred for Linux and smaller, is there
a need for that support?
As the doctext states, I'm open to implementing support for new formats
but I'd rather wait with that till it's needed for anything. Tarballs
are easy to handle, zips are not.
On Thu, 7 Jun 2012 23:49:52 +0200
Michał Górny wrote:
> Of course, if the community insists, I could just update the old
> eclass and fix the ebuilds broken that way.
The following ebuilds would need fixing if -r1 is to replace -r0
in place:
a) naming the tarball ${P}-src.tar.gz:
- de
On Fri, 08 Jun 2012 16:06:27 +0200
hasufell wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/08/2012 03:55 PM, Michał Górny wrote:
> > On Fri, 08 Jun 2012 15:34:32 +0200 Is there a need for that?
>
> I don't know, do you?
Estimated to three
On Thu, 7 Jun 2012 23:49:52 +0200
Michał Górny wrote:
> The idea with the new eclass is to extract all supported archives
> (which means .tar* at the point) into ${WORKDIR} subdirectories
> matching their names. In other words, if you've got:
>
> SRC_URI="http://f
On Tue, 12 Jun 2012 15:09:54 +0200
Michael Weber wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 06/11/2012 04:25 PM, Michał Górny wrote:
> >
> > Committed onto vcs-snapshot.eclass after fixing all in-tree users.
> >
>
> Thanks for the up
slashes and ./ in
> obscure tars/zips but I'd say this tests qualifies for an
> || ewarn "Please check $f for an single parent directory"
> or something like that.
Well, I was hoping to come up with something which doesn't involve
running additional 'tar -t', to
usermod can handle multiple arguments.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
crosoft, or someone, seems to be the only way to easily handle this.
Maybe we could get one such a blob for all distros/systems?
Also, does this signature system have any restrictions on what is
signed and what is not? In other words, will they actually sign a blob
saying 'work-around signatures' on the top?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
uite a good solution. We may also consider defining
src_setup() in new EAPI. Of course, still going this way we'll end up
with src_phase00(), src_phase40() and so on...
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
It is a little confusing when the function reports .a removal when no
such file exists. Also, explain why the file is removed.
---
eclass/eutils.eclass |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index 116f7bc..931d97d 10
On Fri, 15 Jun 2012 11:11:58 -0400
Mike Frysinger wrote:
> On Friday 15 June 2012 09:32:18 Michał Górny wrote:
> > # Remove static libs we're not supposed to link
> > against. if grep -q '^shouldnotlink=yes$' "${f}"; then
> > -
On Fri, 15 Jun 2012 11:11:44 -0400
Michael Orlitzky wrote:
> On 06/15/12 09:32, Michał Górny wrote:
> > It is a little confusing when the function reports .a removal when
> > no such file exists. Also, explain why the file is removed.
>
> Why keep the "-f"
y did with Internet Explorer.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
have enough skills
> to do it, no idea if maybe other dev/people could help on this :/
Zac is already working on this.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
nd of EXTRA_DEPEND
> (or something else) to fit this purpose.
There was already a lot of discussion about this and the community
didn't care enough to agree on one of the proposed solutions. You're
just reinventing one of them, with a new variable name and the same
disadvantages.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
option
> > on their (x86/amd64) platform, they're hardly likely to be a good
> > match for gentoo in any case.
> >
>
> As a user, I'd still like to have the chance of using Secure Boot with
> Gentoo since it _really_ increases security. Even if it means I can no
> longer build my own kernel.
It doesn't. It's just a very long wooden fence; you just didn't find
the hole yet.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
On Sat, 16 Jun 2012 20:49:10 +0200
Pacho Ramos wrote:
> El sáb, 16-06-2012 a las 19:07 +0200, Michał Górny escribió:
> > On Sat, 16 Jun 2012 18:30:55 +0200
> > Pacho Ramos wrote:
> >
> > > El sáb, 16-06-2012 a las 18:09 +0200, hasufell escribió:
> > >
m attaching a reStructuredText version of the spec. You can view it
rendered as a gist[1]. But please keep the replies on the list, rather
than forking the gist.
[1]:https://gist.github.com/2943774
--
Best regards,
Michał Górny
=
Dynamic SLOTs
=
1. Motivation
---
On Sun, 17 Jun 2012 14:09:14 +0200
Thomas Sachau wrote:
> Michał Górny schrieb:
> > Hello,
> >
> > I have prepared a first draft of 'dynamic SLOT' specification. This
> > is my proposal in attempt to solve the problem of building packages
> > for multi
On Sun, 17 Jun 2012 11:43:30 +0200
Hans de Graaff wrote:
> On Sun, 2012-06-17 at 09:26 +0200, Michał Górny wrote:
>
> > I'm attaching a reStructuredText version of the spec. You can view
> > it rendered as a gist[1]. But please keep the replies on the list,
> >
ependency
> syntax that lets you depend on a matching named dynamic slot. That
> makes your DYNAMIC_SLOTS="|| ( py2.6 py2.7 ruby1.8 ruby1.9 )" example
> impossible, but I think it'd be uncommon for that approach to make
> sense: I think it'd usually make more sense to split that into two
> packages, one per language.
Agreed. The next version of the spec (if the goal seemed still possible
to achieve) will certainly have those.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
the rare packages which
> > needs to be provided by the host system instead of being installed
> > in the prefix.
> >
> > Is there something different on BSD which makes libdl.so appear
> > inside the prefix?
>
> At least on OpenBSD dlopen() is not in libdl.so,
On Sun, 17 Jun 2012 11:20:38 +0200
Florian Philipp wrote:
> Am 16.06.2012 19:51, schrieb Michał Górny:
> > On Fri, 15 Jun 2012 09:54:12 +0200
> > Florian Philipp wrote:
> >
> >> Am 15.06.2012 06:50, schrieb Duncan:
> >>> Greg KH posted on Th
like my
> idea for them and want to use your own suggestion for them?
I'm just saying that your framework doesn't change anything for user;
it just involves some work to change the label.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
On Sun, 17 Jun 2012 09:55:35 -0700
Greg KH wrote:
> On Sun, Jun 17, 2012 at 05:51:04PM +0200, Michał Górny wrote:
> > 2. What happens if, say, your bootloader is compromised?
>
> And how would this happen? Your bootloader would not run.
Yes. I'm asking what happens next.
On Sun, 17 Jun 2012 12:56:34 -0400
Matthew Finkel wrote:
> On Sun, Jun 17, 2012 at 11:51 AM, Michał Górny
> wrote:
> > 1. How does it increase security?
> >
> This removed a few vectors of attack and ensures your computer is only
> bootstrapped by and booted using softwa
Hello,
A simple solution to a program long-unsolved. In GLEP form.
Both attached and published as a gist:
https://gist.github.com/2945569
(please note that github doesn't render GLEP headers correctly)
--
Best regards,
Michał Górny
GLEP: XXX
Title: Optional runtime dependencies via ru
On Sun, 17 Jun 2012 21:38:50 +0100
Ciaran McCreesh wrote:
> On Sun, 17 Jun 2012 22:31:59 +0200
> Michał Górny wrote:
> > A simple solution to a program long-unsolved. In GLEP form.
> >
> > Both attached and published as a gist:
> >
> > https://gist.gi
On Sun, 17 Jun 2012 09:26:55 +0200
Michał Górny wrote:
> I'm attaching a reStructuredText version of the spec. You can view it
> rendered as a gist[1]. But please keep the replies on the list, rather
> than forking the gist.
>
> [1]:https://gist.github.com/2943774
U
On Mon, 18 Jun 2012 10:49:37 -0400
Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 17/06/12 11:53 AM, Michał Górny wrote:
> > On Sun, 17 Jun 2012 17:46:00 +0200 Thomas Sachau
> > wrote:
> >>>
> >>> ... I
ested package.
> >
> > This issue could be probably solved through introducing explicit
> > dynamic SLOT dependency atoms.
>
> If you want to do implicit... frankly, you need to create a working
> prototype demonstrating it. That's a high bar requirement I realize,
> but I'm stating it since this is the sort of nasty resolution problem
> where actually *doing* it and seeing how it flies, flexes, etc, is
> critical for proving it's a viable solution for people to rely upon.
>
> Most likely in creating such a beast, you'll wind up simplifying the
> proposal due to sharp edges encountered; that simplification should
> occur w/in the proposal itself rather than having it get passed, then
> people start going "well fuck me sideways, this isn't actually sane
> nor particularly implementable".
>
> Just saying; prototype is required there, frankly for most of this
> proposal in general.
Honestly, I'm not giving it much hope. And certainly I'd like to avoid
hacking around if it's a no-go anyway.
In pseudo-code, I thought about a logic like the following. Feel free
to correct me if this couldn't work.
(where 'slots' here are short for dynamic SLOTs)
current_slots = ('py2.7', 'lib32')
for d in dependencies:
for p in matching_packages(d):
try:
sub_slots = ()
for s in current_slots:
sg = slot_group_for(s)
if p.supports_any_slot(sg.possible_slots):
if p.supports_slot(s):
sub_slots += (s,)
else:
raise DynSlotNotSupported()
parse_package_deps(p, sub_slots)
break
except DynSlotNotSupported:
continue # try next package
else:
raise NoMatchingPackages()
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
ackages which could be taken, teaching users why they are
listed yet not pulled, how to pull and unpull them.
> > - lack of backwards compatibility.
>
> This is a bit of a stretch; to be clear, you're proposing that the
> depgraph changes in subtle/nasty ways on the fly under your scheme,
> and that a PM supporting IUSE_RUNTIME vs one that doesn't, won't find
> new and subtle ways to blow up the packages involved (specifically to
> expose differing behaviour).
It does that already. See 'man emerge', --dynamic-deps.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
changes.
> ║ • EBUILD_PHASE_FUNC.
> ║ • find is guaranteed to be GNU.
> ║ • new* can read from standard input.
> ╙
Could someone open bugs for all of that? I was looking for user patches
on the future EAPI tracker, and I don't see it there.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
On Wed, 20 Jun 2012 12:02:42 +0100
Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 11:07:55 +0200
> Michał Górny wrote:
> > Could someone open bugs for all of that? I was looking for user
> > patches on the future EAPI tracker, and I don't see it there.
>
> Pl
On Wed, 20 Jun 2012 12:14:38 +0100
Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 13:12:25 +0200
> Michał Górny wrote:
> > On Wed, 20 Jun 2012 12:02:42 +0100
> > Ciaran McCreesh wrote:
> > > Please don't. User patches were discussed on this list, and
> >
have to fear
> that your dependency graph will grow just because you didn't examine
> all newly introduced IUSE_RUNTIME flags.
>
> For people who want that stuff unconditionally they could do:
> USE_RUNTIME="$USE"
>
> and never bother again with it.
Please read the rationale. Again. The whole thing. Three times.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
On Wed, 20 Jun 2012 18:24:33 +0100
Ciaran McCreesh wrote:
> On Wed, 20 Jun 2012 19:11:33 +0200
> hasufell wrote:
> > On 06/20/2012 07:07 PM, Michał Górny wrote:
> > > Please read the rationale. Again. The whole thing. Three times.
> >
> > Please read my su
On Thu, 21 Jun 2012 08:30:24 +0100
Ciaran McCreesh wrote:
> On Thu, 21 Jun 2012 09:29:49 +0200
> Michał Górny wrote:
> > On Wed, 20 Jun 2012 18:24:33 +0100
> > Ciaran McCreesh wrote:
> > > On Wed, 20 Jun 2012 19:11:33 +0200
> > > hasufell wrote:
> >
On Thu, 21 Jun 2012 08:41:23 +0100
Ciaran McCreesh wrote:
> On Thu, 21 Jun 2012 09:42:36 +0200
> Michał Górny wrote:
> > > > You just volunteered to write portage patches. Cheers.
> > >
> > > Both were already implemented in Paludis, if you're lookin
On Thu, 21 Jun 2012 20:05:46 +0100
David Leverton wrote:
> Michał Górny wrote:
> > Hello,
> >
> > A simple solution to a program long-unsolved. In GLEP form.
>
> Just a couple of minor points/nitpicks:
>
> 1) If an installed package has both IUSE_RU
On Thu, 21 Jun 2012 21:26:26 +0100
David Leverton wrote:
> Michał Górny wrote:
> > On Thu, 21 Jun 2012 20:05:46 +0100
> > David Leverton wrote:
> >> 1) If an installed package has both IUSE_RUNTIME and REQUIRED_USE,
> >> should REQUIRED_USE be re-verified:
>
Just a short note as it seems some confusion arises lately:
Ciaran McCreesh is not a Gentoo dev and his words don't represent
the position of Gentoo development team.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Would you (or someone else) elaborate on the specific features of bash
> that people find attractive?
Local variables, reasonable behavior (like 'FOO=abc bar' where bar is
macro), arrays, [[ ]] tests (which are obviously faster than calling
external test program).
One more use: printing useful die messages (in POSIX sh there's no way
to do a backtrace).
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
On Thu, 21 Jun 2012 22:32:34 +0100
David Leverton wrote:
> Michał Górny wrote:
> > No, of course not. Otherwise, every package manager run would
> > practically require it to re-validate all packages in the tree
> > (possibly not only installed ones).
> >
> >
valid, to be honest.
There is just a little risk that fast mode wouldn't be used when it
could.
Of course, it's quite unlikely that such an option was actually based
on runtime dep...
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
crews up the meaning.
I think you should start by describing the problem so we all could
understand it, and then we can start thinking about a solution.
Is it that Paludis installs a newer SLOT even if a reverse dependency
explicitly requests another SLOT? Sounds like a bug to me.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
.
Indeed. But reusing revisions is probably saner than abusing
the version number to achieve the same goal.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
quot;a
> newer version" than -r200
It is a newer version. That's why it has a newer revision.
> and that the jruby implementation is not "a
> newer version" than the ruby 1.8 implementation.
And that's another thing which is ugly and should be replaced by
something sane rather than worked around.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
> +unset x
> +
And how does it exactly differ from LANGS above? Is there a reason
those two can't be coerced into a single variable?
Shouldn't those do something more than setting IUSE? For example,
actually ensuring those LINGUAS will be installed?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
On Sat, 23 Jun 2012 18:56:42 +0100
Ciaran McCreesh wrote:
> On Sat, 23 Jun 2012 19:54:13 +0200
> Michał Górny wrote:
> > On Sat, 23 Jun 2012 18:45:46 +0100
> > Ciaran McCreesh wrote:
> > > On Sat, 23 Jun 2012 19:43:10 +0200
> > > Pacho Ramos wrote:
>
On Sat, 23 Jun 2012 19:06:38 +0100
Ciaran McCreesh wrote:
> On Sat, 23 Jun 2012 20:09:03 +0200
> Michał Górny wrote:
> > > That's just it, though -- this no longer holds. -r300 is now being
> > > used for something that is exactly the same version as -r200.
&g
variants depending on how soon they're going to
get the USE correctly.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
On Sat, 23 Jun 2012 19:22:37 +0100
Ciaran McCreesh wrote:
> On Sat, 23 Jun 2012 20:23:13 +0200
> Michał Górny wrote:
> > On Sat, 23 Jun 2012 19:06:38 +0100
> > Ciaran McCreesh wrote:
> > > On Sat, 23 Jun 2012 20:09:03 +0200
> > > Michał Górny wrote:
> &g
le for
> > packages where all dependencies (including any in the world set or
> > the like) are slotted.
>
> Think || ( a:3 a:2 ).
So now that you've stated the problem, maybe it's a good time to find
a proper solution for it.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
On Sun, 24 Jun 2012 16:34:55 +0800
Ben de Groot wrote:
> On 24 June 2012 01:57, Michał Górny wrote:
> > On Sun, 24 Jun 2012 03:37:59 +1000
> > Michael Palimaka wrote:
> >
> >> --- cmake-utils.eclass
> >> +++ cmake-utils.eclass
> >> @@
On Sat, 23 Jun 2012 22:49:30 -0500
Doug Goldstein wrote:
> On Sat, Jun 23, 2012 at 1:26 PM, Michał Górny
> wrote:
> > On Sat, 23 Jun 2012 14:40:50 +0100
> > Ciaran McCreesh wrote:
> >
> >> On Sat, 23 Jun 2012 15:33:47 +0200
> >> Gilles Dartiguelongue
On Sun, 24 Jun 2012 11:58:07 +0100
Ciaran McCreesh wrote:
> On Sun, 24 Jun 2012 10:19:19 +0200
> Michał Górny wrote:
> > > Think || ( a:3 a:2 ).
> >
> > So now that you've stated the problem, maybe it's a good time to
> > find a proper solution for
e are talking about two
> variables and a few lines of code, maybe it would be better to add
> this to base.eclass?
That would change its API and result in possible lot of broken ebuilds.
Not to mention that base eclass currently doesn't require adding
additional phase functions to actually
; I think it would be best to move sys-boot/grub:2 to sys-boot/grub2.
> That should avoid confusion.
If our plan is to replace grub1 with grub2 at some point, that seems
incorrect. In other words, if grub2 is 'natural progress' from grub1.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
sers to those information and inform them about possible
choices.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
de preparation required hint, and allow users to upgrade on
> their own schedule during the usual profile deprecation period.
No-no-no. I don't want profiles suddenly installing grub on my system.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
ell, I gather there's at
> least some upstream eyes following it.
Thinking about it, it probably would be great to have some organized
catalog of flameeyes' posts. Or maybe he should write a book :).
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
SoC is here:
> https://github.com/volpino/euscan
Is the development version running somewhere already so we could play
with it a bit?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
SE
> flags.
Sounds like abuse of '--all' to me. It's like calling 'rm -r' for
single file...
> [1] http://bugs.gentoo.org/421197
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
would be nice to be
> able to set the upstream version manually to 0.71 so that euscan no
> longer reported it as outdated.
I think we could actually handle perl pretty easily. I believe euscan
will start using CPAN API to check the package versions, and we can
embed the normalization there.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
On Thu, 28 Jun 2012 23:18:56 +0200
Pacho Ramos wrote:
> El jue, 28-06-2012 a las 10:26 +0200, Michał Górny escribió:
> > On Wed, 27 Jun 2012 22:12:34 +0300
> > Samuli Suominen wrote:
> >
> > > The logic in prune_libtool_files is not perfect[1].
> >
> &g
ed ABI has been
> > finished, the content of $DESTDIR is checked. If there is no ABI
> > specific content, the other enabled ABIs are skipped and the
> > following steps are done as usual.
>
> In case anyone want some more detail, here's a follow-up question
> from irc:
>
> Tommy[D]: does any ELF executable qualify as "abi specific"
> and trigger builds for all ABIs?
> zmedico: if it goes into any
> of /bin /usr/bin /sbin /usr/sbin and you enable the abiwrapper USE
> flag, yes, otherwise you just request a binary for the default ABI,
> so no need to rebuild everything for no need
How about executables which go into /lib or /libXX?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
s a very good reason (try) to automate it.
>
> I guess something like this might work in pkg_postinst of the portage
> ebuild:
>
> find "$DISTDIR" -maxdepth 1 -type d -uid 0 | xargs chown -R
> portage:portage
find "$DISTDIR" -maxdepth 1 -type d -uid 0 -exec \
chown -R portage:portage {} +
> I would only trigger something like this once, when upgrading from a
> version that doesn't have userpriv enabled by default.
This will work only for users who actually keep those in DISTDIR. Some
of them actually redefine E*_STORE_DIR to a more sane location. But
that's probably irrelevant.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
t; perl-core/quux can and cannot be installed. Because its not *perl*
> that is trying to define what version is installed, but the virtual.
>
> And perl-core/quux can't really block perl , because the whole point
> of perl-core/quux is to be installed on perls other than the ones it
> was shipped with.
>
>
> ^^( ) seems to nicely help solve this problem, and it seems like an
> oversight that we have OR , AND , and NOT dependency rules, but not
> XOR.
>
> P.S. Blame Patrick for this message.
>
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
On Tue, 3 Jul 2012 21:05:46 +1200
Kent Fredric wrote:
> On 3 July 2012 20:24, Michał Górny wrote:
> >
> > --depclean?
>
> eix Module-Metadata
> [I] perl-core/Module-Metadata
> Available versions: ~1.0.3 ~1.0.4 ~1.0.5 1.0.6 ~1.0.9<---
> not unmasked
On Wed, 4 Jul 2012 05:49:08 +1200
Kent Fredric wrote:
> On 4 July 2012 02:16, Michał Górny wrote:
> >> I have thought of scrapping the virtuals entirely and handling it
> >> so that things depend on perl-core/* instead, and perl-core can
> >> just dynamically dec
c/linux and chown to your user. As
far as it goes, it's superior to having kernel sources installed by
ebuilds.
I just have to remember to do 'git fetch' from time to time and 'git
merge' whenever a new version is tagged.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
On Wed, 4 Jul 2012 20:06:58 +0200
Tobias Klausmann wrote:
> Hi!
>
> On Wed, 04 Jul 2012, Michał Górny wrote:
> > There's a very simple yet custom solution I'm using. Shortly saying:
> > checkout the kernel git to /usr/src/linux and chown to your user. As
>
or this would help :-/
>
> Any ideas on this kind of issue?
To be honest, I think the first thing to do would be fixing the test
suites to skip tests which fail due to internet connection being
unavailable. Well, there would still be question how to reliably
determine that...
--
Be
On Sat, 7 Jul 2012 17:46:49 -0400
Alexandre Rostovtsev wrote:
> On Sat, Jul 7, 2012 at 11:21 AM, Michał Górny
> wrote:
> > To be honest, I think the first thing to do would be fixing the test
> > suites to skip tests which fail due to internet connection being
> > unavai
porates it. Or is it
> just an eclass like the others and ebuilds should make sure they
> inherit it if needed?
No. It is unmaintained, has serious design flaws and it simply should
not be used anywhere. At least in EAPI != [01].
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
On Sun, 8 Jul 2012 17:35:08 -0400
Alexis Ballier wrote:
> On Sun, 8 Jul 2012 22:10:02 +0200
> Michał Górny wrote:
>
> > On Sun, 08 Jul 2012 19:49:25 +0200
> > René Neumann wrote:
> >
> > > Hi all,
> > >
> > > I'd like just t
On Sun, 8 Jul 2012 23:40:29 +0200
"Andreas K. Huettel" wrote:
> Am Sonntag 08 Juli 2012, 22:10:02 schrieb Michał Górny:
> > On Sun, 08 Jul 2012 19:49:25 +0200
> >
> > René Neumann wrote:
> > > Hi all,
> > >
> > > I'd like ju
at are you thoughts?
--
Best regards,
Michał Górny
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
EAPI=4
DESCRIPTION="Virtual for libudev providers"
HOMEPAGE=""
SRC_URI=""
LICENSE=""
SLO
On Tue, 10 Jul 2012 12:54:31 -0400
Alexis Ballier wrote:
> On Tue, 10 Jul 2012 17:18:00 +0200
> Michał Górny wrote:
>
> > The former two were previously provided by 'extras' USE flag,
> > and the third was unconditional.
>
> since udev-171 seems to be
101 - 200 of 7473 matches
Mail list logo
