Ciaran McCreesh wrote:
Uh huh, so you add an overlay, and suddenly the dependencies for a
random subset of your installed packages change in ways that don't in
any way reflect what you have installed. How is this the desired
behaviour?
There are several different cases of dependency data
Ciaran McCreesh wrote:
Rich Freeman ri...@gentoo.org wrote:
What would you do away with? Being able to virtualize packages
without recompiling everything that depends on them?
Well that's never worked properly or consistently to begin with
Please answer the question?
//Peter
Manuel Rüger wrote:
virtual/libusb-1-r1 depends on either dev-libs/libusb or
sys-freebsd/freebsd-lib. The latter one is only compatible with
libusb-1.0.9,
You should know that it's the other way around. freebsd-lib isn't to
blame, but =dev-libs/libusb-1.0.18 is.
//Peter
pgpDwzxkEwu11.pgp
Ciaran McCreesh wrote:
Peter Stuge pe...@stuge.se wrote:
Ciaran McCreesh wrote:
Rich Freeman ri...@gentoo.org wrote:
What would you do away with? Being able to virtualize packages
without recompiling everything that depends on them?
Well that's never worked properly
Michał Górny wrote:
Consider the following:
1. A depends on B, both are installed,
2. dependency on B is removed, emerge --depclean uninstalls B thanks
to dynamic-deps,
3. B is treecleaned (nothing depends on it),
So far I follow.
4. old version of A is removed (user doesn't update
Martin Vaeth wrote:
The user has to put a corrected ebuild into his overlay and must
reemerge the package (currently, the latter could be skipped with
dynamic deps).
In fact, no matter whether you have static or dynamic deps, this is
the only way to cleanly avoid the problems if you want to
Martin Vaeth wrote:
The user's vardb could then automatically receive the last state of
the ebuild, before it was removed.
It doesn't help reliably, either, since the last state of the ebuild,
before it was removed, will be outdated at some point, too.
Sorry, I don't see how. Can you give
Martin Vaeth wrote:
The user's vardb could then automatically receive the last state of
the ebuild, before it was removed.
It doesn't help reliably, either, since the last state of the ebuild,
before it was removed, will be outdated at some point, too.
Sorry, I don't see how. Can
Samuli Suominen wrote:
let users do the rebuild (which is the obvious answer
to the output you posted)
Reality check time, Samuli.
Unless emerge says Your dependencies are b0rk, please rebuild $P to fix it.
that answer is nowhere near obvious.
Watch out with the tunnel vision.
//Peter
Duncan wrote:
(Hmm... my client's warning says I'm not verbose enough, too much quoted
text for my reply. /That/ doesn't happen very often! After adding this
note it's the continue anyway button. =:^)
Here is a friendly reminder for everyone;
Please remove more quoted text. Full-quote in
Kent Fredric wrote:
dependencies are forward specifications from upstream telling
us what their software needs to function properly.
Unfortunately that's not the full story. :\
ebuilds often (for me) have artificial dependencies, when the actual
version required is too old to be in the tree,
Rich Freeman wrote:
If upstream happens to say it requires foo-1.5, by all means just
take their word for it and list it,
Don't take their documentation's word for it however, but look at
what the build actually requires. (E.g. configure.ac.)
//Peter
Duncan wrote:
Red Hat is the gold standard, very long term commercial support,
IIRC 10 years, and very good community relations
I've heard this on occasion, but reality is actually quite different.
Red Hat is a software service provider. They do whatever their paying
customers ask for. They do
Michał Górny wrote:
( source ${f} || die sourcing ${f} failed )
2b. Unless someone knows a way around this, this means that the check
-- unless 'die'-fatal -- needs to ensure non-zero status of last
comment, likely via some trailing 'true' or ':'. Since we can't
distinguish between
Jauhien Piatlicki wrote:
Emerging live ebuild usually is quite a risky thing,
I don't know. It depends on the culture of the particular repository,
and while it is true that many open source repos are utter crap I'm
not sure if that is the common case?
I like to believe that developers actually
Jauhien Piatlicki wrote:
The question is not about crap in the upstream, but about changed
dependencies, behavior, whatever else.
That's a good point.
E.g. we in downstream have some patches, when upstream changes
related code (e.g. applying our patches), ebuild fails to build.
I consider
Michał Górny wrote:
What I need others to do is provide the hosting for git repos.
I'm happy to set up repos on my git server with custom hooks and
accounts as needed.
It's probably not what we want long-term, but it might be useful as
proof of concept, so that infra only needs to do setup one
Patrick Lauer wrote:
That'd mean I need half a dozen checkouts just to emulate cvs, which
somehow doesn't make much sense to me ...
Unlike CVS, git doesn't force you to work in Keep millions of files in
uncommitted states mode just to work on a codebase, due to the commit -
Rich Freeman wrote:
If you just want to do 15 standalone commits before you push you can
do those sequentially easily enough. A branch would be more
appropriate for some kind of mini-project.
..
That is the beauty of git - branches are really cheap.
So are repositories
And commits.
Not
Rich Freeman wrote:
If you want to satisfy yourself I believe you can get git to dump
the contents of any object without formatting/etc.
git ls-tree HEAD .
git show $blobhash
git show --pretty=raw HEAD
//Peter
Diamond wrote:
I stumbled over this problem when started to use git for packages.
Use git show -M to unstumble yourself.
//Peter
Diamond wrote:
we probably can arrive at a conclusion that git itself isn't good
at all for package management.
I don't think we can. Please stop the nonsense, at least until you
have created something superior to git.
//Peter
Rich Freeman wrote:
I sill think it makes more sense to start with a threat model and go
from there.
I agree. It's a great project to tackle after the migration.
For migrating I agree with you that it's fine to do whatever.
Really. This year. As in before 2015. There are three more months.
Rich Freeman wrote:
I've so far gotten zero feedback on my hosting offer, intended to
help find some starting processes.
hassufel's repository on github should be more than adequate:
https://github.com/gentoo/gentoo-gitmig
The very first email in this thread pointed out that it is
Jonathan Callen wrote:
the correct response would be to ensure that the final commit
pushed (whether it be a merge commit or rebased) contains the
stabilization for both arches
I think this is one of the things to check in a post-receive or
post-update hook. What is the easiest way to access
hasufell wrote:
A version bump plus cleaning up older ebuilds will be considered
one logical change, I suppose?
I'd consider it two logical changes
..
But I don't have a strong opinion on that
I do - I think this is really important. Having clean history makes a
huge difference for anyone
Jorge Manuel B. S. Vicetto wrote:
I've stopped following this mailing list regularly quite sometime ago.
To see this thread is still going on and no one bothered to cc releng,
to me shows a lack of respect
I expected you to participate on the developer list to some degree,
since you are
Hey Jorge,
Jorge Manuel B. S. Vicetto wrote:
I know that our policies state that technical issues should be raised in
the dev ml, although they also support doing the discussion in specialized
mls, but they also mention that one should make an effort to contact those
involved in the
Steven J. Long wrote:
it's a bit late for that
It's never too late to improve.
//Peter
Steven J. Long wrote:
On Tue, Sep 30, 2014 at 07:52:02AM -0700, Zac Medico wrote:
The IPC implementation that I've suggested does not involve an SUID
helper, so it is much more secure. Security would rely on the permission
bits of the named pipes that are used to implement IPC.
..
I don't
Michał Górny wrote:
Remove the code responsible for recognizing which branch HEAD pointed
out to since it was unsafe and unnecessarily complex. A proper match is
not really necessary since all operations can be safely performed on
an opaque 'HEAD' (or rather refs/git-r3/HEAD since fetching to
Steven J. Long wrote:
It's a lot more secure to have a single well-defined privileged trust
anchor (the privileged process) with a well-defined protocol, than to
have built-in privilege escalation which allows arbitrary actions.
You appear to have missed the point of what it does.
I
Michał Górny wrote:
the new framework is opt-out rather than opt-in.
Why is it desirable to make that change?
//Peter
pgpAbh_XiMjXl.pgp
Description: PGP signature
Rich Freeman wrote:
the new framework is opt-out rather than opt-in.
Why is it desirable to make that change?
there is no longer a performance penalty
There is a severe behavioral penalty!
We think that most users will prefer to just leave everything enabled now.
I really do not want
Peter Stuge wrote:
There is a severe behavioral penalty!
Rich Freeman wrote:
I really do not want that to be chosen for me.
Well, then all you need to do is tell eselect to disable them, etc.
Well, but see above - this is a huge change in behavior - I really
don't think that should be done
Alexis Ballier wrote:
- why not adding a clang subprofile ? there's one for amd64-fbsd; I had
been able to build a complete stage 3 without too much trouble.
There's probably nothing bsd specific there, so moving
generic code from there to profiles/features should work.
I'd try to test
Ian Stakenvicius wrote:
OK, i've cobbled something together that looks like it'll work.
Cool! Thanks a lot for doing that.
//Peter
Andrés Martinelli wrote:
I am working on a terminal spreadsheet based on sc, but with some adds
like undo/redo..
you can find it here:
https://github.com/andmarti1424/scim
Any new ideas and/or contribution is always welcome!
See also teapot. Right, an undo stack is a nice feature.
William Hubbs wrote:
I'm just wondering what the default should be.
..
Does anyone have any comments on that approach?
I think the Gentoo default should just be what upstream uses and
documents.
//Peter
pgpcub1K1GUj7.pgp
Description: PGP signature
Michael Mol wrote:
4) Jer marked #530478 as a dupe of #426262,
To me that looks bogus. #530478 is about app-office/dia while #426262
is about two eclasses.
Jeroen - please explain why you consider 530478 a duplicate of 426262?
I note that you did not do so in Bugzilla while marking the dupe,
Rich Freeman wrote:
How about contact instead of team.
there is no meaning to a contact besides being CC'ed on bugs.
Please simply call it cc then? :)
//Peter
Rich Freeman wrote:
I personally find it annoying when people fork projects, decide not to
maintain ABI compatibility with the original project, and then keep
filenames the same/etc such that the packages collide in their
recommended configurations.
Some people do it on purpose, with
Rich Freeman wrote:
working out things 1:1 if possible
..
it is probably better to let Comrel do their job, rather than
having everybody bicker on the list.
Working out things 1:1 *on the list* is nice in that it adds transparency.
Of course, it is then also very easy for people to send
Patrick Lauer wrote:
they can all be fixed.
Let's not tolerate mediocrity.
All you can do is to try to set an example, but you'll likely find
that most of the time, nobody is willing to live with the tradeoffs
for excellence - the obvious one being perceived slower development.
Countless
Patrick Lauer wrote:
Do you, as QA team member, think that a review workflow improves quality?
No.
Bureaucracy does not improve quality by itself.
A review workflow isn't about bureaucracy, it's about review. :)
Now, review means different things to different people, and some will
Joshua Kinard wrote:
Using seed stage3 stages I built 6 months ago (but never released due
to getting sidetracked), I run into errors like this:
!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:
Rich Freeman wrote:
This is part of the set of topics which we
cover outside the scope of the quizzes.
A brief comment from reality is that this legal problem is quit
likely a significant hurdle for many potential developers - as for me.
If you want contributing to be easy, overhead
Justin (jlec) wrote:
This is part of the set of topics which we
cover outside the scope of the quizzes.
A brief comment from reality is that this legal problem is quit
likely a significant hurdle for many potential developers - as for me.
If you want contributing to be easy, overhead like this
Rich Freeman wrote:
I personally find it annoying when people fork projects, decide not to
maintain ABI compatibility with the original project, and then keep
filenames the same/etc such that the packages collide in their
recommended configurations.
Some people do it on purpose, with the
Michał Górny wrote:
Title: USE=libav introduction
Author: Micha?? G??rny mgo...@gentoo.org
Your mailer doesn't set charset for the .txt attachment.
Content-Type: text/plain
Posted: 2015-01-yy
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: media-video/ffmpeg
Display-If-Installed:
Rich Freeman wrote:
Would this work:
gpg --gen-key
option 2 - DSA and Elgamal
Watch that entropy.
//Peter
$ grep :harfbuzz profiles/use*desc
profiles/use.local.desc:dev-libs/efl:harfbuzz - Enable complex text shaping and
layout support.
profiles/use.local.desc:dev-qt/qtgui:harfbuzz - Use media-libs/harfbuzz for
text shaping (experimental in Qt 5.3.x, default in Qt 5.4.0 and later). If
enabled, it
hasufell wrote:
from what comments I got back no one really wanted to join (at least
under the current system). I wasn't going to force the games team to
elect a new lead when it appears none cared much at that point who
the lead was. Also, I would advise caution on considering it
Andreas K. Huettel wrote:
0. What names for the tree/repository.
gentoo
IMO this is the only really accurate name.
(it's also the repo_name)
There you go. It already has the name gentoo. :)
portage doesn't make sense, everything else is too long or
potentially confusing...
Yes
Jason A. Donenfeld wrote:
Calling it gentoo makes sense, because the entire tree is what makes
gentoo.
Exactly. And the repo already has this name set in repo_name.
But since it's namespaced in ebuilds/ and because ebuilds/
might have other gentoo-official repos too, then perhaps
Rich Freeman wrote:
Calling it gentoo makes sense
The thing is, Gentoo is more than a bunch of ebuilds.
Sure, but the gentoo ebuild repo is just a bunch of ebuilds.
Gentoo as name can and should be used elsewhere too of course.
Certainly they're a HUGE part of Gentoo, but they alone
Nicol TAO wrote:
so. believe it or not?
Communication should reduce confusion, not risk increasing it.
//Peter
Ben de Groot wrote:
Title: FFmpeg default
Posted: 2015-04-01
Bad date for such news.
//Peter
Ben de Groot wrote:
I propose that we prefer installing just OpenType. But this should
be user configurable, so in those cases I propose we do:
IUSE=+opentype
if use opentype; then
FONT_SUFFIX=otf
else
FONT_SUFFIX=ttf
fi
So if I first USE=-opentype and later
Guilherme Amadio wrote:
We could have global USE flags for each popular font format, turn on the
flag for OpenType by default, and let users choose extra formats they
want.
I like this suggestion very much. This is exactly what I want from Gentoo.
Another thing we might want to work on is
Ben de Groot wrote:
I propose that we prefer installing just OpenType. But this should
be user configurable, so in those cases I propose we do:
IUSE=+opentype
if use opentype; then
FONT_SUFFIX=otf
else
FONT_SUFFIX=ttf
fi
So if I first USE=-opentype and later USE=opentype the
Anthony G. Basile wrote:
On 02/22/15 12:08, Nicolas Sebrecht wrote:
* Fun is lost for a long time.
This is is extremely false.
It's a very subjective matter. I don't doubt that Gentoo is fun for
some or many or even all developers. I also have no doubt that the
process of becoming a developer
Andrés Martinelli wrote:
Hello there!
As many of you already pointed, the spreadsheet app SCIM I am working on,
collides in its name with Smart Common Input Method.
I decided that is time to change its name to avoid problems and to get lost
with the other.
What are your suggestions?
I
Anthony G. Basile wrote:
The way gcc is dealing with this is that it is NOT bumping the soname
so we can get libraries linking aginst libstdc++.so with the wrong abi
and you get breakage.
..
I'm not sure how to solve this one
Is there any alternative to implementing the different sonames in
Rich Freeman wrote:
I find email an incredibly frustrating experience all-around. It
works great as long as everybody doesn't use anybody for hosting who
isn't in the top-10 provider list, and doesn't use a mailing list.
DMARC marks top-10 essentially creating their own walled email garden.
Robin H. Johnson wrote:
Why should we not be able to benefit from really good closed-source
CI tools that are offered for free to the open-source community?
Because it may not be in line with Gentoo politics.
Jenkins, Buildbot and others are existing libre options in this
ecosystem, but
Yanestra wrote:
after a talk with some of the persons present here, it appears, Gentoo
Linux is actually something like a Freemason lodge.
I disagree with this.
I do agree that the threshold to become a developer with write access
to the gentoo repo is very high, which is why I'm not a
Rich Freeman wrote:
Jenkins, Buildbot and others are existing libre options in this
ecosystem, but aren't keeping pace with development.
Politics that somehow matter usually require compromise.
The (rhetorical) question is, what is most important?
..
The only choices we actually have
James Le Cuirot wrote:
Pacho Ramos pa...@gentoo.org wrote:
As that USE flag should only be used for being able to install the
package the first time, maybe it should be treated in a special
way. I mean, it shouldn't be easily changed by users but, instead,
switched internally by the
Andrew Savchenko wrote:
we should not solely rely on third-party proprietary solutions
(travis is a github lock-in) because of convenience.
We must not.
//Peter
pgp10MsxnxXNc.pgp
Description: PGP signature
Ben de Groot wrote:
I see no reason to stick with libav as default, except political
(which I'm trying to avoid here).
It's very convenient to try to ignore politics, but IMO that's no
better in open source than on election day. A default is always a
political choice.
With any choice, the
hasufell wrote:
This is something that has to be resolved upstream. If they don't
cooperate long-term, then their fork will just die out for sure
(and for good).
I agree that this is what one would intuitively expect, but what
actually happens is that whatever is perceived as most mainstream
Duncan wrote:
The point you made here was console-based workflow, as quoted above,
and that's what I addressed, arguing that even if was valid at some
point, it's no longer the factor it once was.
For you, that is. Be aware that this creates your bias. You can't
extrapolate from your own
Michał Górny wrote:
dev-util/atomic-install
A nice one -- tool to quasi-atomically install files from $D to live
system. The idea is to replace live files as fast as possible,
and quickly revert that if it fails in the middle.
I like the idea, but I would personally like to see it
William Hubbs wrote:
If we do add a code review system, it should be fully accessible from
the command line. Pybugz is almost there for bugzilla; the only thing it
lacks is the ability to reply to specific comments.
Gerrit is also almost there, it has an ssh interface which is very
usable for
C Bergström wrote:
To start I hate git.. I have used it for years now and the
multitude of ways that are possible to accomplish nearly the same
thing are *annoying* at best..
I'd be interested to hear a couple of examples of what you mean,
perhaps in a private mail. Tack på förhand. :)
NP-Hardass wrote:
or do they typically restrict review to a certain class of users?
Hm, why would that end up happening? I'm not saying it can't, just
that I don't understand why it would. What do you have in mind?
Well, it was just proposed earlier in the thread that it could be
used
C Bergström wrote:
1) Rebase doesn't obscure history,
That's plain wrong. Rebasing changes the parent of your commit. That
means that others can no longer see the history of your commit,
specifically its original parent. Sometimes the parent is irrelevant,
sometimes it is critical.
(Unless
C Bergström wrote:
3) Ever tried to make a patch of the *actual* merge commit? Can one of
the advocates of merge show me the git command to do that? (Sure you
can diff between 2 commits, but the merge commit likes to avoid
being seen)
If there are no conflicts when merging then the
William Hubbs wrote:
I think I understand what he's asking for...
I think he is asking the question, What changed in commit hash.
If you use the hash of a merge commit with git show, you get nothing,
so the merge commit is useless in terms of following changes.
I have explained why merge
Alec Warner wrote:
Its difficult to make a large change like all commits require review,
particularly for long-time contributors who are expecting to move quickly.
I think it's a character flaw (maybe hubris due to lack of experience
and/or ignorance?) to lack the humility to say that I would
hasufell wrote:
that said... I don't think it currently makes sense to enforce
a strict global review workflow.
For the record, neither do I, and I never proposed that it should
hold up starting to use Git.
//Peter
William Hubbs wrote:
[1] http://www.semver.org
Major version zero (0.y.z) is for initial development. Anything may change
The problem is that version 0 hit stable
Just treat version numbers as the meaningless counters they are.
I can't just randomly break things from 0.17 to 0.18 for
Hi and happy Git days! :)
Robin H. Johnson wrote:
It expands to the hash of the blob of that file; and from that, you can
identify which commits the blob exists in.
$ git ls-tree HEAD README
100644 blob 08ae16956b8944da2fef75fee892dcba457cf4f0README
$
$ (stat --printf='blob %s\0'
Sergey Popov wrote:
qt? (
qt5? ( dev-lang/qtcore:5 )
!qt5? ( dev-lang/qtcore:4 )
)
Fine by me, if you would ask.
May I suggest instead:
qt? (
qt5? ( dev-lang/qt$something:5 )
qt4? ( dev-lang/qt$something:4 )
)
Alexandre Rostovtsev wrote:
qt? (
qt5? (
Michael Orlitzky wrote:
> Once users have the full git repo on their machines, they have two
> options. They can update it efficiently with `git pull`, or they can
> update it with rsync by using `emerge --sync`. You can even mix the two,
I don't think you can mix the two, because how my local
Michael Orlitzky wrote:
> after making those three revbumps, what I see is that I added and
> removed the entire ebuild three times. True, but useless.
Try git show/log -M
//Peter
Anthony G. Basile wrote:
> if you emerge when using a vanilla kernel or some other which doesn't
> support user.pax.* on tmpfs, then you'll loose those markings.
Would it be at all possible to add the markings after/as files land
on the destination filesystem instead?
It's not really intuitive
Anthony G. Basile wrote:
>> Would it be at all possible to add the markings after/as files land
>> on the destination filesystem instead?
..
> since we sometimes have to do pax markings during src_compile() or
> src_test() or early during src_install() etc, the safest approach is to
> preserve
Rich Freeman wrote:
I suspect that trying to force it would basically end up putting
the entire distro on hold until most of the current devs quit,
I think you're right. I also think those developers should quit right
here and now. I don't think they will.
//Peter
Robin H. Johnson wrote:
> However, the largest sticking point, even with parallel threads, is that
> it seems the base ChangeLog generation is incredibly slow. It averages
> above 350ms per package right now (at 19k packages in a full cycle, it's
> a long time), but some packages can take up to 5
upstream hat on
Kent Fredric wrote:
I've always seen it as a case where Gentoo devs stand as a layer of
sanitization between downstream and upstream.
This is the last thing I want. Did you play the whisper game as a kid?
I want direct contact with the user who can reproduce the problem in
the
Stefan G. Weichinger wrote:
> * the former dev has removed himself as maintainer
> * the package is rather outdated now in portage
> * there are some ebuilds already which could be considered to be added
> (at least as unstable, sure)
>
> pls advise,
If you have interest in this package then you
Robin H. Johnson wrote:
> 1. Script #1 (helper), that given an ebuild, spits out the filenames of the
>distfiles.
>- Use an explicitly specified PORTDIR for eclasses.
>- Must NOT rely on the ebuild directory structure (i'd love to give
>it the ebuild via stdin and tell it the
Rich Freeman wrote:
> a big question is how to make it happen without just throwing
> complaints on the folks who are trying their best to keep it all going.
The answer to this is the same as it has always been:
Demonstrate that you are capable and reliable and given social
compatibility then
Ulrich Mueller wrote:
> (If directories are really needed, we could use the scheme foreseen
> in [1] for package.* and use.* files.)
So package.{users,group} ?
> Also a mechanism how a subprofile could undefine a user or group
> defined in its parent seems to be missing.
Maybe set the id to -1
Michael Orlitzky wrote:
> If anyone has a concrete idea that works better, it's not too late to
> change it.
Add code to init script and service file to check the config before
starting the program, and react if PHP5 is still set.
//Peter
Kristian Fiskerstrand wrote:
> Maybe I'm thinking things too difficult, why not just define both -D
> PHP and -D PHP5 in the transition period and suggest this config for
> any change?
Because it mostly just defers the problem.
If the desire is to move away from PHP5 then I would suggest to
Michael Orlitzky wrote:
> >> If anyone has a concrete idea that works better, it's not too late to
> >> change it.
> >
> > Add code to init script and service file to check the config before
> > starting the program, and react if PHP5 is still set.
>
> Which init script?
For Apache.
> It's
Rich Freeman wrote:
> I'm not sure it is really worth trying to control this via a USE flag
> for such a light dependency.
I don't care how light dependencies are - I want to be able to choose
every single one that is optional. That is Gentoo's killer feature,
and I am thoroughly disappointed
301 - 400 of 528 matches
Mail list logo
