On Mon, Dec 7, 2015 at 7:05 PM, Alec Warner wrote:
> I think there are a few issues:
>
> 1) Not everyone cares. I think you can either go for an opt-in approach
> (hard..you need to keep state) or offer clear opt-out / filtering
> instructions (link in the bottom of the email that points at the op
On Sun, Dec 6, 2015 at 12:26 PM, Ian Stakenvicius wrote:
>
>> On Dec 6, 2015, at 11:52 AM, Rich Freeman wrote:
>>
>>> On Sun, Dec 6, 2015 at 11:09 AM, Michael Orlitzky wrote:
>>> On 12/06/2015 11:00 AM, Michał Górny wrote:
>>>>>
>>>>
On Sun, Dec 6, 2015 at 11:09 AM, Michael Orlitzky wrote:
> On 12/06/2015 11:00 AM, Michał Górny wrote:
>>>
>>> Of course. Add the commit author, too: I want to know if I break someone
>>> else's package.
>>
>> So far, can't do that since we don't know which commit exactly broke. I
>> don't want to
On Sat, Nov 21, 2015 at 1:51 PM, Andrew Savchenko wrote:
>
> On Wed, 18 Nov 2015 07:01:21 -0500 Rich Freeman wrote:
>> On Wed, Nov 18, 2015 at 6:12 AM, Alexander Berntsen
>> wrote:
>> > When I do QA in projects I'm involved with (at least outside of
>> >
On Fri, Nov 20, 2015 at 4:39 AM, Patrick Lauer wrote:
>
> On 11/18/2015 01:01 PM, Rich Freeman wrote:
>> On Wed, Nov 18, 2015 at 6:12 AM, Alexander Berntsen
>> wrote:
>>> When I do QA in projects I'm involved with (at least outside of
>>> Gentoo), we d
On Wed, Nov 18, 2015 at 10:10 AM, Brian Dolbec wrote:
> On Wed, 18 Nov 2015 06:59:19 -0500
> Rich Freeman wrote:
>
>> Actually, what is less clear to me is how portage versioning actually
>> works, or if we attach any meaning to the version numbers at all.
>> Both the
On Wed, Nov 18, 2015 at 7:06 AM, Alexander Berntsen wrote:
> We are talking about people who run Gentoo stable who need to
> keyword several specific packages because the lack of manpower
> leads to Gentoo stable by itself not being very usable for most
> people.
>
In this case, however, I don't
On Wed, Nov 18, 2015 at 6:12 AM, Alexander Berntsen wrote:
> When I do QA in projects I'm involved with (at least outside of
> Gentoo), we don't do it live on end-user systems. I'll leave the
> details as an exercise for the Gentoo developer.
>
People who run ~arch are not really end-users - they
On Wed, Nov 18, 2015 at 6:05 AM, Ulrich Mueller wrote:
>
> And on what basis would you stabilise Portage, when there are no
> ebuilds in the tree to test its EAPI 6 code?
>
As long as the EAPI6 code in the new portage is no more broken than
the EAPI6 code in the current stable version of portage
On Tue, Nov 17, 2015 at 8:54 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Gentoo has never really guaranteed the stability of a mostly-stable
> system with a few ~arch accept-keyworded packages as that's simply not a
> properly testable setup.
>
True, but Gentoo has never really guaranteed much of
On Tue, Nov 17, 2015 at 3:37 PM, Raymond Jennings wrote:
> As a possibly relevant side note, I've observed how api changes are handled
> in the linux kernel:
>
> You can change whatever you want if it's a good idea, but as part of proving
> it, you have to be willing to take over the warranty for
On Mon, Nov 16, 2015 at 4:52 AM, Alexis Ballier wrote:
> On Mon, 16 Nov 2015 10:29:43 +0100
> "Justin Lecher (jlec)" wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> On 16/11/15 10:14, Alexis Ballier wrote:
>> > Probably those that want to ban it should fix the(ir) tree so tha
On Tue, Nov 3, 2015 at 10:04 AM, Chí-Thanh Christopher Nguyễn
wrote:
> Matt Turner schrieb:
>>
>> The git transition had been 9 years in the making and has massively
>> improved Gentoo development. Look at the graph of contributions per month:
>> https://www.openhub.net/p/gentoo
>
> I'd like to po
On Tue, Nov 3, 2015 at 2:22 AM, Patrick Lauer wrote:
> Apparently my complaining finally re-triggered some action, so sadly
> this looks like the currently best strategy.
You could have simply made a simple post pointing out that changelog
generation appears to be broken and likely had the same e
On Tue, Nov 3, 2015 at 1:43 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Tho I get Dale's somewhat confused and now belabored point as well. For
> people who don't know how to do git on their own, as clearly he doesn't,
> the official signaling of what the stopgap changelog alternatives were
> unt
On Mon, Nov 2, 2015 at 9:31 PM, Dale wrote:
> That is why a link was posted for me to use github instead. I
> do realize and understand that git and github are two different things
> but it seems they can work together as well. It ended up that the info
> I needed was on github but not to be fou
On Mon, Nov 2, 2015 at 8:20 PM, Dale wrote:
> I thought Gentoo was not depending on git/github either.
Take 5min and read the wikipedia articles on both git and github, please.
Gentoo is not going to depend on github, because of the social contract issues.
Gentoo absolutely does depend on git,
On Mon, Nov 2, 2015 at 1:24 AM, Patrick Lauer wrote:
>
> On 11/02/2015 02:56 AM, Rich Freeman wrote:
>> On Sun, Nov 1, 2015 at 8:22 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>>> I know if I were still on rsync (or webrsync), I'd be raising hell about
>>&g
On Mon, Nov 2, 2015 at 1:08 AM, Dale wrote:
>
> Then perhaps all this should have been worked out BEFORE switching to
> github?
We didn't switch to github.
>
> I don't mind change but it seem this one wasn't really ready to be done
> yet although most made it sound like it was.
IMO we took too
On Sun, Nov 1, 2015 at 8:22 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> I know if I were still on rsync (or webrsync), I'd be raising hell about the
> lack of
> changelogs well before now
Perhaps rather than raising hell you'd do better to raise money to
hire an infra team to fix the bug or somet
On Sun, Nov 1, 2015 at 3:33 PM, Martin Vaeth wrote:
> Please do not break all these possibilities for users
> who do not have to waste the resources for a full git
> clone and want to see regularly ChangeLogs nevertheless!
I don't think anybody has proposed breaking anything. It sounds like
it i
On Sun, Nov 1, 2015 at 10:29 AM, Martin Vaeth wrote:
> Rich Freeman wrote:
>>
>> What discussion or decision is necessary?
>> What is needed is for those who want changelogs
>> to fix the bug
>
> The bug can only be fixed by somebody who knows
> the details ho
On Sun, Nov 1, 2015 at 10:24 AM, Alexis Ballier wrote:
> On Sun, 1 Nov 2015 10:17:54 -0500
> Rich Freeman wrote:
>>
>> I haven't heard anybody propose a new plan. I certainly am not
>> proposing one.
>
> The part you cut:
>
>>
>> You shouldn&#
On Sun, Nov 1, 2015 at 10:00 AM, Alexis Ballier wrote:
> On Sun, 1 Nov 2015 09:19:25 -0500
> Rich Freeman wrote:
>
> [...]
>> What discussion or decision is necessary?
>
> One that announces the initial and current plan has changed and
> describes the new plan maybe?
On Sun, Nov 1, 2015 at 8:47 AM, Alexis Ballier wrote:
> Considering the original plan was to have changelogs auto-generated
> from git and still serving the tree via rsync, where's the relevant
> discussion and decision about this?
What discussion or decision is necessary? As far as I'm aware no
On Sun, Nov 1, 2015 at 7:33 AM, Мисбах-Соловьёв Вадим wrote:
> And why don't just only generate them on rsync mirrors, but remove them from
> git repo (like was planned initially, AFAIRC)?
>
That is in fact how it works. Or, at least how it is supposed to
work. I don't use the rsync mirror, so
On Fri, Oct 30, 2015 at 5:16 PM, Anthony G. Basile wrote:
> On 10/30/15 3:35 PM, hasufell wrote:
>>
>> On 10/30/2015 06:55 PM, Michał Górny wrote:
>>>
>>> We have no way of saying 'I prefer polarssl, then gnutls, then
>>> libressl, and never openssl'.
>>
>> I don't think this is something that can
On Fri, Oct 30, 2015 at 1:55 PM, Michał Górny wrote:
>>
>> The pain is for a short time. Then we have to live with this for a
>> long time. USE flags should have one meaning. The fact that this
>> isn't the case right now is already a bug. We don't need to
>> perpetuate it.
>
> No, the pain is
On Wed, Oct 28, 2015 at 7:16 AM, hasufell wrote:
>
> This is outside of the scope of this thread, but there are already
> distros that have fixed this:
> 1. NixOS [0] with truly declarative configuration format, e.g. something
> like:
> packages.ssl.provider = openssl;
Well, we can accomplish thi
On Tue, Oct 27, 2015 at 10:06 PM, hasufell wrote:
>
> B) 1 feature flag, 3 strict provider flags
> * ssl: enable any sort of SSL/TLS support
> * gnutls: only to enable gnutls provided ssl support in case there
> is a choice
> * openssl: only to enable openssl provided ssl support in case
On Wed, Oct 21, 2015 at 4:44 AM, Anthony G. Basile wrote:
>
> I pushed out my news item and it landed in /usr/portage/metadata on my
> hardened servers, but its not showing up with eselect news. Does anyone
> know why?
1. Do you have hardend-sources installed?
2. Do you have either hardened or
On Tue, Oct 20, 2015 at 5:22 AM, Alexis Ballier wrote:
>
> Ok, that's what I'd call "forced correctness" :)
> But again, theory tells you that if you want algorithmically checkable
> correctness then you have to seriously limit your possibilities, which
> is why I usually don't even consider this
On Tue, Oct 20, 2015 at 3:51 AM, Alexis Ballier wrote:
> On Mon, 19 Oct 2015 15:49:06 -0400
> Rich Freeman wrote:
>
> It's not about correctness vs convenience: eapply_user idempotent
> doesn't prevent from doing it correctly. It makes it possible to do it
> incor
On Tue, Oct 20, 2015 at 4:23 AM, Daniel Campbell wrote:
> However, does this mean the hardened kernel package must stay in ~arch
> since it's technically the testing version? Or would we keyword it
> based on our own findings of stability?
I'd recommend that the team does whatever adds the most v
On Mon, Oct 19, 2015 at 1:55 PM, hasufell wrote:
> On 10/19/2015 07:52 PM, Rich Freeman wrote:
>> On Mon, Oct 19, 2015 at 1:40 PM, hasufell wrote:
>>> On 10/19/2015 07:37 PM, Rich Freeman wrote:
>>>>
>>>> However, stabilizing a single package really
On Mon, Oct 19, 2015 at 2:28 PM, Alexis Ballier wrote:
>
> However, as you say, putting it in cmake-utils needs to be properly
> thought so that it doesn't conflict with other eclasses: Hence the need
> to properly define what eclasses should call eapply_user and apply
> patches and what should no
On Mon, Oct 19, 2015 at 1:40 PM, hasufell wrote:
> On 10/19/2015 07:37 PM, Rich Freeman wrote:
>>
>> However, stabilizing a single package really is an impactful change.
>> The fact that you're doing 100 of them at one time doesn't really
>> diminish the i
On Mon, Oct 19, 2015 at 1:13 PM, hasufell wrote:
>
> We already know that. But if e.g. ago runs his scripts at 00:00 with
> ~300 packages stabilized, the history (without git command line) on
> github/gitweb will be fun to read (and people DO that).
>
It doesn't seem like it would have been any b
On Mon, Oct 19, 2015 at 10:21 AM, Alexis Ballier wrote:
> On Mon, 19 Oct 2015 09:51:20 -0400
> Rich Freeman wrote:
> [...]
>> >
>> >> I'd say the best approach for compatibility if you have an existing
>> >> eclass and it already exports src_pre
On Mon, Oct 19, 2015 at 11:27 AM, Ian Stakenvicius wrote:
>
> Ahh, so what you're referring to here is stabilization of multiple
> unrelated packages in a single commit.. ok.. i'm not so
> comfortable with that idea..
Nor am I. A commit should be a set of related changes. Stabilizing
all of K
(To avoid repeating the same exception over and over, please
understand that nothing said below is intended to apply to the
do-everything eclasses used by KDE/etc, where the eclass and ebuilds
are carefully maintained in conjunction with each other.)
On Mon, Oct 19, 2015 at 9:34 AM, Alexis Ballier
On Mon, Oct 19, 2015 at 3:12 AM, Alexis Ballier wrote:
> But there is something important we've overlooked: should eclasses that
> export src_prepare call eapply_user ? I think yes, otherwise they'd
> make packages inheriting them violate the 'at least once rule'.
This sort of thing has been disc
On Mon, Oct 19, 2015 at 7:55 AM, Dirkjan Ochtman wrote:
> On Mon, Oct 19, 2015 at 1:21 PM, hasufell wrote:
>> I'd go so far to say allow people to do commits like:
>> """
>> amd64 stabilizations
>>
>>
>> """
>> possibly pre-pending the rough domain like "kde", if any. I think kde
>> herd already
On Sun, Oct 18, 2015 at 8:44 AM, Ciaran McCreesh
wrote:
>
> But the big gain for everyone is in replacing a weird, overly clever
> and highly fragile collection of weirdness that's designed to mostly
> accept any dodgy input, with one that just gets you to give it a sane
> input to begin with.
>
On Sun, Oct 18, 2015 at 8:05 AM, hasufell wrote:
>
> If you are messing with the build system in a patch, there is no
> guarantee that eautoreconf will be enough. It might or might not be true
> (see net-irc/hexchat for an example). Are we going to run eautoreconf
> unconditionally then (which is
On Sun, Oct 18, 2015 at 7:37 AM, hasufell wrote:
> On 10/17/2015 08:03 PM, Ciaran McCreesh wrote:
>> On Sat, 17 Oct 2015 14:49:36 +0200
>> hasufell wrote:
>>> You can apply the patches post_unpack or post_src_prepare witht hooks.
>>> What's the problem?
>>
>> Running autorecrap.
>>
>
> You can do
On Sun, Oct 18, 2015 at 6:17 AM, Ulrich Mueller wrote:
>> On Sun, 18 Oct 2015, Michał Górny wrote:
>
>> On Sun, 18 Oct 2015 11:54:40 +0200
>> Ulrich Mueller wrote:
>
>>> So the question is if we should add a sentence like the following to
>>> the spec:
>>>
>>> In EAPIs where it is supported,
On Sat, Oct 17, 2015 at 8:52 AM, Ulrich Mueller wrote:
>
> That eapply_user is called can be enforced by repoman, or by a QA
> warning.
>
I hate to reply again on the same topic, but how would repoman even
know whether eapply_user will always get called? Isn't that
equivalent to the halting prob
On Sat, Oct 17, 2015 at 8:51 AM, Michał Górny wrote:
> Dnia 2015-10-17, o godz. 08:38:51
> Rich Freeman napisał(a):
>
>> On Sat, Oct 17, 2015 at 8:25 AM, hasufell wrote:
>> > On 10/17/2015 02:19 PM, Jason A. Donenfeld wrote:
>> >>
>> >> The ot
On Sat, Oct 17, 2015 at 8:49 AM, hasufell wrote:
>
>> The other feature that is supposed to be in EAPI6 (I didn't read the
>> draft yet) is that the PM should refuse to install the package if
>> eapply is never called (ie src_prepare is overridden and the ebuild
>> didn't call eapply). It is requ
On Sat, Oct 17, 2015 at 8:25 AM, hasufell wrote:
> On 10/17/2015 02:19 PM, Jason A. Donenfeld wrote:
>>
>> The other question is more critical -- could you merge eapply and
>> eapply_user? Or add some hook to PMS so that eapply_user isn't needed?
>> IOW, it'd be nice if every package was, by defau
On Fri, Oct 16, 2015 at 2:45 AM, Alexis Ballier wrote:
>
> if it's just used by catalyst to pre-seed world then indeed pms
> doesn't have anything to do with it, but if it's meant to be some set
> that profiles add to 'world' set dynamically, then interoperability is
> probably desired
>
I'd sugg
On Thu, Oct 15, 2015 at 6:00 PM, Zac Medico wrote:
> On 10/15/2015 02:51 PM, Anthony G. Basile wrote:
>
>> The only change in moving it to @profile is the warning.
>
> What's the point of getting rid of the warning if the package is going
> to get pulled back in on the next @world update? Either w
On Thu, Oct 15, 2015 at 5:15 PM, Zac Medico wrote:
> On 10/15/2015 02:03 PM, Rich Freeman wrote:
>> On Thu, Oct 15, 2015 at 4:57 PM, Zac Medico wrote:
>>> Given the goals, having catalyst seed /var/lib/portage/world seems
>>> pretty reasonable to me.
>>
>>
On Thu, Oct 15, 2015 at 4:57 PM, Zac Medico wrote:
> Given the goals, having catalyst seed /var/lib/portage/world seems
> pretty reasonable to me.
Then the question becomes how. Does it diff @profile between the two
profiles and put the extra stuff in @selected? Or, does the profile
just contai
On Thu, Oct 15, 2015 at 4:10 PM, Zac Medico wrote:
> What's probably desired is to create a stage3 profile which adds
> whatever extra stuff you want to @system, and to use the stage3 profile
> for to build stage3. After the stage3 is built, catalyst could set some
> other profile if we don't want
On Thu, Oct 15, 2015 at 11:34 AM, Mike Frysinger wrote:
>
> items to sort out:
> - should the list of packages be in catalyst or profile-stacked content
> -> imo it should be entirely in the profile
++
This would be really nice to combine with mix-ins so that instead of
special cases we could ju
On Thu, Oct 15, 2015 at 7:58 AM, Alexander Tsoy wrote:
>
> I was wrong. This patch was not merged upstream. It is still needed and
> included in latest genpatches for 4.2:
>
> $ tar tf genpatches-4.2-6.base.tar.xz | grep XATTR
> ./1500_XATTR_USER_PREFIX.patch
I suspect what we all have in common
On Thu, Oct 15, 2015 at 7:22 AM, Tobias Klausmann wrote:
>
> So it's not a BTRFS problem, but one of tmpfs. So I wondered if I
> maybe had missed to activate xattr suport for tmpfs, but no:
>
> # zgrep -i tmpfs /proc/config.gz
> CONFIG_DEVTMPFS=y
> CONFIG_DEVTMPFS_MOUNT=y
> CONFIG_TMPFS=y
> CONFIG
On Thu, Oct 15, 2015 at 6:56 AM, Jason Zaman wrote:
>
> Can you try this:
>
> # getfattr -d -m- /bin/ping
> security.capability=0sAQAAAgAgAAA=
> # setfattr -n user.test -v "foo" ./ping
> # setfattr -n user.pax.flags -v "me" ./ping
> # getfattr -d -m- /bin/ping
> security.capability
On Wed, Oct 14, 2015 at 11:39 PM, Mike Frysinger wrote:
> iputils is currently in @system for everyone. by default, it only
> installs `ping`. do we feel strongly enough about this to require
> all systems include it ? or should this wait for the long idea of
> releasing stage4's instead of sta
On Mon, Oct 12, 2015 at 1:44 PM, Alec Warner wrote:
>
>
> On Mon, Oct 12, 2015 at 3:58 AM, Rich Freeman wrote:
>>
>> On Sun, Oct 11, 2015 at 11:35 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> >
>> > It is, however, worth repeating that in git, commi
On Mon, Oct 12, 2015 at 9:29 AM, Ian Delaney wrote:
>
> Not sure how to read this. The whole idea is for provider / client to
> communicate and negotiate a workable solution. At a glance this reads
> as the user needs to adapt to the service that the client is offering
> and appease the provider.
On Sun, Oct 11, 2015 at 11:35 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> It is, however, worth repeating that in git, commits are entirely
> separate from pushes and are very (as in, extremely!) cheap, while
> pushes, particularly if properly repoman-checked, are obviously much more
> expensive.
Ok, in the Council meeting today the following was made policy:
"Maintainers must not assume that dynamic dependencies will be applied
by the package manager. When changing runtime dependencies the
maintainer should revision the ebuild if the changes are likely to
cause problems for end users."
Th
On Sun, Oct 11, 2015 at 7:09 AM, Rich Freeman wrote:
> So, here is a consolidated list of the latest proposals:
>
It has been suggested that there might be rare cases where the
exceptions in the eclass proposals might apply to ebuilds, so doing
some refactoring I think the latest proposa
On Thu, Sep 17, 2015 at 7:57 AM, Kristian Fiskerstrand wrote:
>
> Another thing that strikes me is separation of stable vs ~arch behavior.
>
> This applies in particular with in-place eclass alterations. Users on
> ~arch should normally expect more activity (in particular number of
> builds and ch
On Fri, Oct 2, 2015 at 5:46 AM, Rich Freeman wrote:
> On Fri, Oct 2, 2015 at 2:22 AM, Martin Vaeth wrote:
>> Rich Freeman wrote:
>>>
>>> Proposal 3a might be: Anytime an RDEPEND in an eclass is changed, the
>>> eclass must be revisioned unless all ebuil
On Sat, Oct 10, 2015 at 10:15 AM, hasufell wrote:
>
> Nevertheless, we'll try to continue, reduce public noise and keep the
> reviews useful.
>
Bugs would probably be helpful from the standpoint that they also are
a mechanism to keep track of whether the issue was corrected.
I don't think it is
On Tue, Oct 6, 2015 at 8:27 PM, Zac Medico wrote:
>
> Yeah, there can be a benefit, as long as you're not one of the people
> who uses --changed-deps for all updates (revbumps for dependency changes
> are basically irrelevant to these people).
>
Presumably those inclined to do this would be likel
On Tue, Oct 6, 2015 at 12:44 PM, Zac Medico wrote:
> On 10/06/2015 06:33 AM, William Hubbs wrote:
>> I don't think the revbump of net-misc/openconnect-7.06-r1 to -r2 was
>> necessary. When the change purely affects use flags, that is picked up
>> by the pm and there is no need to force everyone to
On Mon, Oct 5, 2015 at 11:28 AM, Jason A. Donenfeld wrote:
> I assume there are developers hard
> at work adding the flag to each and every package.
Keep in mind that it isn't always a drop-in replacement. If it were
we'd just make a virtual for libssl and you wouldn't need to mess with
flags at
On Fri, Oct 2, 2015 at 2:22 AM, Martin Vaeth wrote:
> Rich Freeman wrote:
>>
>> Proposal 3a might be: Anytime an RDEPEND in an eclass is changed, the
>> eclass must be revisioned unless all ebuilds in the gentoo repository
>> will continue to work correctly with the
On Thu, Oct 1, 2015 at 3:08 PM, Ian Stakenvicius wrote:
>
>>
>> RDEPEND changes in eclasses Proposal 3: Anytime an RDEPEND in an
>> eclass is changed, the eclass must be revisioned. Proposal 4:
>> Anytime an RDEPEND in an eclass is changed, all ebuilds that
>> inherit the eclass in the gentoo repo
On Wed, Sep 16, 2015 at 1:09 PM, Rich Freeman wrote:
>
> I'll go ahead and start a tangent on this thread right here. As a
> first step can we separately consider the proposal to require a
> revbump anytime a package's RDEPENDS changes? I'm referring here to
> di
On Wed, Sep 30, 2015 at 3:29 PM, Anthony G. Basile wrote:
>
> Yes you could use symbol versioning, and you can do the side by side by
> renaming the library but that's a real pita for us since we'd have to hack
> build systems to link against the correct library name. Ths should have
> been done
On Wed, Sep 30, 2015 at 8:10 AM, Kristian Fiskerstrand wrote:
>
> On 09/30/2015 01:51 PM, Rich Freeman wrote:
>>
>> I think it was fair to pause to see if somebody could come up with
>> a better solution that allows co-existence, but absent that I
>> don't se
On Wed, Sep 30, 2015 at 7:29 AM, Kristian Fiskerstrand wrote:
>
> The way I see it this is relevant to the discussion at hand.
Admittedly it is a bit tangential, but it didn't seem worth forking
the thread over. Certainly I'm not going to invent my own mailing
list and post it there, and then po
On Wed, Sep 30, 2015 at 2:35 AM, Paweł Hajdan, Jr.
wrote:
> On 9/29/15 3:32 PM, Rich Freeman wrote:
>> The thing is that I think the libressl authors are shooting themselves
>> in the feet. When upstreams do this sort of thing they think they're
>> making the upgrade p
On Tue, Sep 29, 2015 at 9:43 AM, hasufell wrote:
> On 09/29/2015 03:32 PM, Rich Freeman wrote:
>> [...]
>
> I have waited 9 days. I don't see a reason to wait another few weeks,
> just because you like to bikeshed a lot.
I don't recall suggesting that you should wai
On Tue, Sep 29, 2015 at 8:22 AM, hasufell wrote:
> No useful comments, so I will proceed as outlined in the transition plan.
>
I don't think your attitude is going to win you a lot of friends, and
I don't think that we're better off for it.
That said, I've yet to hear a workable alternative, and
On Sun, Sep 20, 2015 at 12:57 PM, hasufell wrote:
> On 09/20/2015 06:47 PM, Manuel Rüger wrote:
>> On 20.09.2015 16:26, hasufell wrote:
>>> On 09/20/2015 03:27 PM, Manuel Rüger wrote:
Please stop introducing further tree-wide changes regarding libressl.
>>>
>>> That's not possible, because in
On Sun, Sep 20, 2015 at 9:27 AM, Manuel Rüger wrote:
> On 19.09.2015 23:04, hasufell wrote:
>> Friends,
>>
>> I think it is time to import LibreSSL[0]. There are not many packages
>> left that don't compile OOTB and those can be patched (e.g. dev-lang/ruby).
>>
>> My idea would be:
>>
>> 1. import
On Sun, Sep 20, 2015 at 7:14 AM, hasufell wrote:
> On 09/20/2015 08:07 AM, Andrew Savchenko wrote:
>> Greetings,
>>
>> On Sat, 19 Sep 2015 23:04:14 +0200 hasufell wrote:
>>> Friends,
>>>
>>> I think it is time to import LibreSSL[0]. There are not many packages
>>> left that don't compile OOTB and
On Sun, Sep 20, 2015 at 5:50 AM, Alexis Ballier wrote:
>
> Yes, that's what gnome team is doing with gtk2 vs gtk3; however, I'm
> not sure how much work it is. Only package I know of providing
> different slots depending on what it's built upon is webkit-gtk.
>
> I can't imagine every library usin
On Sat, Sep 19, 2015 at 7:32 PM, Raymond Jennings wrote:
> Is it possible for projects to be nested, possibly within multiple
> super-projects?
>
> Like, for example, a project dealing with a gnome chat client itself being
> members of both the gnome and the chat projects (hypothetically speaking)
On Sat, Sep 19, 2015 at 5:07 PM, Daniel Campbell wrote:
> +1 in general, but I'm a little pensive about allowing non-devs to
> become official project members. Becoming a developer can be a
> grueling process, so I understand that some don't have the time or
> motivation, and still want to help ou
On Fri, Sep 18, 2015 at 5:16 AM, Kristian Fiskerstrand wrote:
> I do sincerely hope package maintainers
> have a well thought out setup for key management locally and in fact
> verify the OpenPGP signatures vs known good keys, and that appropriate
> measures are being taken in the case of non-main
On Fri, Sep 18, 2015 at 1:10 AM, Michał Górny wrote:
> Dnia 2015-09-17, o godz. 17:19:17
> Michael Orlitzky napisał(a):
>
>> Replying somewhere randomly with an idea.
>>
>> Since projects are now on the wiki, why don't we use that as the
>> canonical source of project members? It's machine readab
On Thu, Sep 17, 2015 at 8:22 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> So council was called in, and it asked the portage folks to take some
> steps that, portage development being what it is, had the effect of
> slowing down and delaying things for long enough that, hopefully, people
> have had t
On Thu, Sep 17, 2015 at 7:20 AM, Anthony G. Basile wrote:
> On 9/17/15 7:05 AM, James Le Cuirot wrote:
>>
>> On Thu, 17 Sep 2015 06:57:08 -0400
>> "Anthony G. Basile" wrote:
>>
>>> Totally rethink the idea of emails aliases as something that is
>>> created on the fly. We just need to know who sh
On Wed, Sep 16, 2015 at 4:44 PM, Ian Stakenvicius wrote:
>
> - - emerge -uD @world would update the dep anyhow
>
> - - emerge -u @world wouldn't rebuild the package if that package
> didn't change, and if the package did change then the new dep would
> get built.
Just to be clear, my point was th
On Wed, Sep 16, 2015 at 5:25 PM, Michał Górny wrote:
>
> So, what are your thoughts for unmessing this?
>
This sounds familiar. :)
Honestly, I wouldn't mind combining them all. Just today I was pinged
by an !expn in IRC and thought to myself, "how many times have I typed
the wrong command to t
On Wed, Sep 16, 2015 at 4:17 PM, Michał Górny wrote:
>
> If you modify an eclass, you're responsible for the outcome. Even if
> means revbumping hundreds of ebuilds for the sake of it. Note that this
> is the kind of revbump that wouldn't require resetting stable keywords
> as long as deps are sat
On Wed, Sep 16, 2015 at 3:31 PM, Michał Górny wrote:
>
> As for virtuals and eclasses, I don't really understand why anyone
> thinks they are special in any regard. In both cases, we're talking
> about regular dependency change in metadata, and we need to understand
> the consequences. And they're
On Wed, Sep 16, 2015 at 11:49 AM, Andreas K. Huettel
wrote:
> Hi all,
>
> here's a quote from the Council 20140826 summary:
>
>> Dynamic dependencies in Portage
>> ===
>> During discussion, is was remarked that some changes, e.g. to
>> dependencies in eclasses, could re
On Tue, Sep 15, 2015 at 3:56 PM, Robin H. Johnson wrote:
> On Tue, Sep 15, 2015 at 02:13:34PM +0200, hasufell wrote:
>> On 09/15/2015 02:00 PM, Peter Stuge wrote:
>> > If you have interest in this package then you can do one or more of:
>> > * become a Gentoo developer (ha-ha)
>> hmm
> For backgro
On Sun, Sep 13, 2015 at 9:02 PM, Raymond Jennings wrote:
> I agree. I think that any "master" version of whatever repo we use should
> be hosted on gentoo owned infrastructure.
>
> Github might be allowed to take pull requests but I think it should be a
> slave to whatever's hosted on gentoo.
>
>
On Sat, Sep 12, 2015 at 6:00 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Just bite the bullet and create entire USE flag families such that an
> ebuild can choose the flag appropriate to how it actually uses it. AFAIK
> this would need EAPI help, for reasons given below, but it should be
> doable
On Sat, Sep 12, 2015 at 12:55 AM, Raymond Jennings wrote:
> On Fri, Sep 11, 2015 at 5:13 AM, Rich Freeman wrote:
>>
>> On Fri, Sep 11, 2015 at 5:03 AM, Daniel Campbell wrote:
>> >
>> > I like the general 'gtk' flag we generally use to choose *w
701 - 800 of 2195 matches
Mail list logo
