On Wed, Sep 17, 2014 at 4:02 PM, Diamond wrote:
> On Mon, 15 Sep 2014 14:51:56 -0400
> Rich Freeman wrote:
>>
>> In general you want each commit to represent a single "change." That
>> might be a revbump in a single package, or it might be a package move
>
On Thu, Sep 18, 2014 at 1:53 PM, Ulrich Mueller wrote:
>> On Thu, 18 Sep 2014, Tobias Klausmann wrote:
>
>> However, one aspect of how ebuilds are written these days will
>> cause a non-trivial amount of merge commits that are not actually
>> useful in that sense.
>
Git can do merge conflict
On Thu, Sep 18, 2014 at 3:33 PM, Diamond wrote:
> Lets assume, that I don't want to scrap old ebuild yet. There's no git
> cp command. git mv is just git rm + git add. That's what does it look
> like (usual revbump with git add in reality):
> https://github.com/cerebrum/dr/commit/311df9b04d876f584
On Fri, Sep 19, 2014 at 10:25 AM, hasufell wrote:
>
> That is pretty easy and takes you ~20s for a keyword merge. What's the
> problem?
>
Agree. Also, there was a comment that git pull is much slower than
cvs. While it is true that git does refresh the whole tree all the
time, it is FAR more ef
On Sat, Sep 20, 2014 at 10:28 AM, hasufell wrote:
> Ian Stakenvicius:
>>> I wonder if it would make sense to set up a practice git tree
>>> somewhere so that people can try working together on workflows/etc.
>>> We can clone a migrated tree (I have one from a few days ago on
>>> github).
>>
>> Def
On Sat, Sep 20, 2014 at 12:48 PM, hasufell wrote:
> Steven J. Long:
>
>> Either way, I don't think the discussion about Changelogs should *at all*
>> affect the move to git;
>
> Correct, because this wouldn't even be a regression to the current CVS
> workflow.
>
That depends a great deal on how
On Sat, Sep 20, 2014 at 2:09 PM, Ulrich Mueller wrote:
>> On Wed, 17 Sep 2014, Aaron W. Swenson wrote:
>
>> My argument is Git using SHA-1 for checksumming is not the weakest
>> part of our security model.
>
> I had always assumed that robbat2's series of GLEPs (57 to 61) would
> be implemente
On Sat, Sep 20, 2014 at 4:40 PM, Ulrich Mueller wrote:
>> On Sat, 20 Sep 2014, hasufell wrote:
>
>>> Have these plans been abandoned, and are we now planning to
>>> distribute the tree to users via Git, where everything goes through
>>> the bottleneck of a SHA-1 sum, which was never intended
On Sat, Sep 20, 2014 at 8:58 PM, Gordon Pettey wrote:
> You're following the wrong train down the wrong tracks. Git [0-9a-f]{40} is
> to CVS 1[.][1-9][0-9]+. You're arguing that CVS is more secure because its
> commits are sequential numbers.
Ulrich is well-aware of that. His argument is that wi
On Sat, Sep 20, 2014 at 9:27 PM, Peter Stuge 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
If we need history we can always
On Sun, Sep 21, 2014 at 9:08 PM, Peter Stuge wrote:
> 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 rea
On Mon, Sep 22, 2014 at 12:10 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Devs doing gentoo all day could easily do one or two pushes a day, with
> many commits in each. Those with less time might do the same work over
> several days or a week and might push just once or twice that week, if
> non
On Mon, Sep 22, 2014 at 8:42 AM, Michał Górny wrote:
>
> Also, CVS gets your name wrong. I wonder how it is possible with such
> an awesome modern piece of technology ;).
>
CVS itself does support unicode in the commit messages. I have no
idea where the name comes from in the emails that go out,
On Mon, Sep 22, 2014 at 10:50 AM, Ulrich Mueller wrote:
>> On Mon, 22 Sep 2014, hasufell wrote:
>
https://wiki.gentoo.org/wiki/Gentoo_git_workflow
>
But so far, not many people have been particularly interested in
the details of these things. I'm also not sure if the ML is the
On Mon, Sep 22, 2014 at 12:52 PM, W. Trevor King wrote:
> On Mon, Sep 22, 2014 at 11:29:52AM -0400, Rich Freeman wrote:
>> On Mon, Sep 22, 2014 at 10:50 AM, Ulrich Mueller wrote:
>> > Another issue, should we require "Signed-off-by:" lines? At least
>> > for
On Mon, Sep 22, 2014 at 2:28 PM, W. Trevor King wrote:
> On Mon, Sep 22, 2014 at 02:13:53PM -0400, Rich Freeman wrote:
>> Perhaps the c clause should be clarified that the source files
>> themselves were not modified - not the commit message.
>
> The DCO text is verbatim
On Mon, Sep 22, 2014 at 3:27 PM, W. Trevor King wrote:
> On Mon, Sep 22, 2014 at 03:13:35PM -0400, Rich Freeman wrote:
>> On Mon, Sep 22, 2014 at 2:28 PM, W. Trevor King wrote:
>> > On Mon, Sep 22, 2014 at 02:13:53PM -0400, Rich Freeman wrote:
>> >> Perhaps the c c
On Mon, Sep 22, 2014 at 3:43 PM, W. Trevor King wrote:
> There's no Signed-off-by on the commits adding the DCO to the Linux
> tree ;). The only information I can find claiming copyright and
> licensing by one of the DCO authors is at
> http://developercertificate.org/. I suppose you could alter
On Wed, Sep 24, 2014 at 12:31 PM, W. Trevor King wrote:
> On Wed, Sep 10, 2014 at 04:18:40PM +0200, Michał Górny wrote:
>>
>> 4. A mail alias that is not project :). For example, we have clang@ for
>> easily aggregating all clang-related build failures and other bugs but
>> it isn't a formal team.
On Thu, Sep 25, 2014 at 11:29 AM, W. Trevor King wrote:
>
> What about a entry in metadata.xml that points people to the
> suggested mailing list for discussing a package? Bugzilla could
> automatically add the list to its CC list, and both devs and non-devs
> could join the list without adding
On Sat, Sep 27, 2014 at 4:58 AM, Jeroen Roovers wrote:
>
> Right now, CC'ing a single alias is inconvenient, but under your
> proposal, you might need to CC a dozen or more people instead of that
> alias.
>
That is incorrect. Herds would be replaced with projects, not with
lists of individual (n
On Sat, Sep 27, 2014 at 6:51 AM, Jeroen Roovers wrote:
> On Sat, 27 Sep 2014 06:25:28 -0400
> Rich Freeman wrote:
>
>> On Sat, Sep 27, 2014 at 4:58 AM, Jeroen Roovers
>> wrote:
>> >
>> > Right now, CC'ing a single alias is inconvenient, but under your
On Sat, Sep 27, 2014 at 6:13 PM, Tom Wijsman wrote:
> The question becomes "does every herd want to become a (sub)project?".
>
So, there was some discussion on -dev, apparently some discussion I
wasn't a part of, and some that I was (such is the nature of IRC).
I think it would make sense to tak
On Sat, Sep 27, 2014 at 5:52 PM, Tom Wijsman wrote:
>
> What is really needed here is a vote by the Council on whether to add bc
> back to the stage3. If the people do insist, another vote regarding
> adding or changing an editor to stage3 could be done as well.
>
The call for agenda goes out on
On Sat, Sep 27, 2014 at 7:39 PM, Anthony G. Basile wrote:
> And now for something completely different ... drum roll ... Really! We
> have to have a council vote on whether bc goes into stage3? If this does go
> to the council, then I want a pre-vote vote: should we bounce the decision
> back to
On Mon, Sep 29, 2014 at 12:05 AM, Jorge Manuel B. S. Vicetto
wrote:
>
> No, there isn't a need for a Council vote here. This is something up to
> Releng (in respect to what is in the stages) and to everyone in respect to
> what is part of the system set.
I don't think many really care about defer
On Mon, Sep 29, 2014 at 7:53 AM, Anthony G. Basile wrote:
> Although, I must say, Jorge's is being little premature here, and I
> doubt the Council will act rashly.
So, while I was trying to be balanced in my reply, I'll admit it may
have still been a bit too emotionally motivated.
I think this
On Mon, Sep 29, 2014 at 7:09 PM, Ulrich Mueller wrote:
>> On Tue, 30 Sep 2014, Jeroen Roovers wrote:
>
>> Please provide some examples of when and how that piece of
>> information, "herd", is important.
>
> Don't shift the burden of proof, please.
>
Meh, knowing if the status quo is useful is
On Tue, Sep 30, 2014 at 3:00 AM, Ulrich Mueller wrote:
>
> I had just given some reasons above, in the part that you haven't
> quoted.
>
My main issue was with the "burden of proof" bit. This isn't a court
- we're free to do whatever seems to make the most sense, and not
worry about what kind of
On Wed, Oct 1, 2014 at 7:59 AM, 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
> i
On Fri, Oct 10, 2014 at 5:31 PM, W. Trevor King wrote:
> On Fri, Oct 10, 2014 at 09:22:18PM +, Robin H. Johnson wrote:
>> In a similar vein, would releng be open to moving stage1/2/3 package
>> sets to virtual packages or package sets? Presently they are inside
>> catalyst, and I think this wo
On Sat, Oct 11, 2014 at 1:25 AM, Steven J. Long
wrote:
> Not arguing with your use-case. Just wondering why ed and bc are considered
> such major burdens, but polkit+systemd+udev+dbug+glib+glibc+godknows are a
> minimal base.
Nobody is talking about adding most of that stuff to the @system set.
On Sat, Oct 11, 2014 at 4:07 PM, M. Ziebell wrote:
>
> But if anyone would ask me to stabilize gcc-4.8 I would say "amd64 ok".
>
If there is general consensus that this is going to be a stable target
it might make sense to start running mixed stable+gcc-4.8 systems as
widely as possible for feedb
On Sat, Oct 11, 2014 at 5:27 PM, Anthony G. Basile wrote:
>
> I would say the following still should be fixed:
>...
>
> These look like some namespace issues, and different use of registers (on
> x86). #46 is hardened specific.
Do any of these actually apply to non-hardened amd64? I picked
On Sun, Oct 12, 2014 at 8:23 AM, Anthony G. Basile wrote:
> I'm working on that. I'm not sure that #46 is hardened i686 specific
> right now. I'm hitting it on vm with even the vanilla gcc so something else
> might be going on here.
VLC built fine on stable amd64 with near-default make.conf
On Mon, Oct 13, 2014 at 9:56 AM, Duncan <1i5t5.dun...@cox.net> wrote:
>
> Many of our users do care what's going on, that's why they run gentoo,
> and for those that don't, a bit of extra information won't hurt 'em.
>
Sure, though it may help to format things from a more "actionable"
standpoint.
On Mon, Oct 13, 2014 at 12:52 PM, Peter Stuge wrote:
> Michał Górny wrote:
>> the new framework is opt-out rather than opt-in.
>
> Why is it desirable to make that change?
>
>
> //Peter
Disregard previous fat-finger reply...
On Mon, Oct 13, 2014 at 12:52 PM, Peter Stuge wrote:
> Michał Górny wrote:
>> the new framework is opt-out rather than opt-in.
>
> Why is it desirable to make that change?
>
See my previous email:
3. Unlike in the past, there is no longer a performance pena
On Mon, Oct 13, 2014 at 7:32 PM, Peter Stuge wrote:
>
> I really do not want that to be chosen for me.
>
> Opt-out is not cool. :(
>
Well, then all you need to do is tell eselect to disable them, etc.
It always seemed pointless to me that there are a million bash
completion filters installed on
On Tue, Oct 14, 2014 at 6:56 PM, Alex Xu wrote:
> I feel like there should be a DEPEND specifier for "packages required to
> build against this package". For example, xproto is required to build
> against SDL (at least using pkg-config), but not to simply use it at
> runtime. This applies even if
On Wed, Oct 15, 2014 at 7:42 AM, Andreas K. Huettel
wrote:
>> In order to solve bug #503802 [1], I would like to add a
>> virtual/podofo-build package to pull in app-text/podofo and
>> dev-libs/boost. Then packages like app-text/calibre can put
>> virtual/podofo-build in DEPEND and app-text/podofo
On Sun, Oct 19, 2014 at 8:10 AM, Andreas K. Huettel
wrote:
> Am Samstag, 18. Oktober 2014, 19:34:52 schrieb Pacho Ramos:
>> >
>> > Perhaps a stupid question, but: why is it a problem if the logs are
>> > linked rather than attached?
>>
>> Supposedly we always must attach files to bug reports to en
On Mon, Oct 20, 2014 at 9:47 AM, Martin Vaeth wrote:
> Anthony G. Basile wrote:
>>> Since gcc-4.7 there is a -std=c++11 option, do not use it {+yet+}
>>> since it breaks the ABI, resulting in a non-functional system.
>>
>> Yes. Eventually we'll have to clear the road for this.
>
> Isn't Diego ju
On Tue, Oct 28, 2014 at 11:37 PM, Vadim A. Misbakh-Soloviov
wrote:
> Btw, since Gentoo do not (mostly) provide packages itself, but only build
> instructions (ebuild), can't we just ship ebuild that "patches" openldap
> violates to force to use db6>=19 with "bindist" USE?
>
Can we do it legally?
On Fri, Oct 31, 2014 at 12:28 PM, Diego Elio Pettenò
wrote:
> On 19 October 2014 16:57, hasufell wrote:
>>> If maintainers want to NEEDINFO or WONTFIX a tinderbox bug, well,
>>> they'll be the ones picking up the pieces when the gcc upgrade moves
>>> ahead.
>>
>> We are all picking up the pieces.
On Fri, Oct 31, 2014 at 12:25 PM, Luca Barbato wrote:
>
> lu - hoping rust won't have such issues.
>
Funny - I first heard of this earlier this week. Biggest issue I see
with rust is that it seems like it has joined the
every-language-needs-its-own-package-manager club, and it seems to me
that i
I'm going to speak generally - this is a list and not really the best
way of dealing with individuals. If you think the principles apply to
you, feel free to apply them.
On Fri, Oct 31, 2014 at 7:50 PM, Diego Elio Pettenò
wrote:
> I'm more convinced than ever that either someone else (Council? Q
On Sat, Nov 1, 2014 at 11:38 AM, hasufell wrote:
>
> But there will be no improvement if we don't take such issues more
> seriously. I don't really see that happening. It's something the
> oldtimers have more power over than the council.
>
In a community project, the folks with power are those do
On Sat, Nov 1, 2014 at 2:30 PM, Andreas K. Huettel wrote:
>
>> The newest member of Gentoo can have more power to direct the course
>> of the distro than every oldtimer or council member there is, if they
>> just contribute more than them.
>
>> If the maintainer of package A or provider of service
> On Tue, 9 Sep 2014 21:45:49 +0200
> Michał Górny wrote:
>>
>> Let's keep it short: I think herds don't serve any special purpose
>> nowadays. Their existence is mostly resulting in lack of consistency
>> and inconveniences.
>>
Resurrecting this thread per the last council decision:
"The counci
On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny wrote:
>
> # This eclass contains backports of functions that were accepted
> # by the Council for the EAPI following the EAPI used by ebuild,
> # and can be implemented in pure shell script.
I'm not sure that I like this sort of a moving-target defini
On Thu, Nov 6, 2014 at 4:38 PM, Ciaran McCreesh
wrote:
> On Thu, 6 Nov 2014 22:32:17 +0100
> Jeroen Roovers wrote:
>> On Thu, 06 Nov 2014 12:40:33 -0800
>> Zac Medico wrote:
>> > On 11/06/2014 12:11 PM, Michał Górny wrote:
>> > > # multilib.eclass collisions
>> > > get_libdir() { future_get_libd
On Thu, Nov 6, 2014 at 5:09 PM, Andreas K. Huettel wrote:
> Am Donnerstag, 6. November 2014, 22:56:21 schrieb Rich Freeman:
>>
>> I think we are well-served by taking Ciaran's advice here. Utility
>> eclasses should just passively export functions. Anything that does
On Thu, Nov 6, 2014 at 5:03 PM, Zac Medico wrote:
> On 11/06/2014 01:53 PM, Rich Freeman wrote:
>> On Thu, Nov 6, 2014 at 3:11 PM, Michał Górny wrote:
>>>
>>> # This eclass contains backports of functions that were accepted
>>> # by the Council for the EA
On Fri, Nov 7, 2014 at 1:01 PM, Zac Medico wrote:
>
>> I'm still concerned that in general we tend to have packages hang
>> around at older EAPIs for a long time as it is. That isn't really a
>> problem if those EAPIs are stable and supported for a while. This
>> seems likely to complicate thing
On Sat, Nov 8, 2014 at 2:48 PM, hasufell wrote:
> On 11/08/2014 08:32 PM, hasufell wrote:
>> On 11/08/2014 08:01 PM, Matthias Dahl wrote:
>>> Hello Ciaran...
>>>
>>> On 08/11/14 19:26, Ciaran McCreesh wrote:
>>>
No. It would make sense to introduce a cultural change, where
developers sto
On Thu, Nov 13, 2014 at 5:30 AM, Michael Palimaka wrote:
>
> In general, a package must explicitly depend upon what it directly uses.
> However, to avoid ebuild complexity and developer burden there are some
> exceptions. Packages that appear in the base system set may be omitted
> from an ebuild'
On Thu, Nov 13, 2014 at 10:07 AM, Michael Palimaka
wrote:
>
> Ditching implicit dependencies is an interesting idea but not practical.
> Nobody wants to the laundry list, and there's little benefit in
> maintaining a virtual/system clone of @system.
>
Well, the idea would be to maintain the virtu
On Thu, Nov 13, 2014 at 9:38 PM, Michael Palimaka wrote:
> On 14/11/14 11:06, Rich Freeman wrote:
>>
>> Well, the idea would be to maintain the virtual INSTEAD of @system, or
>> have @system just pull in the virtual and make some arch-specific
>> additions.
>
&
On Fri, Nov 14, 2014 at 7:20 AM, Anthony G. Basile wrote:
>
> Sorry Zac, I posted my reply before I read this. This is essentially the
> point I was making. However, I think this will be cumbersome. With the
> current way we do things, its easy to delete packages from @system by just
> doing '-
On Fri, Nov 14, 2014 at 1:22 PM, Ciaran McCreesh
wrote:
> On Fri, 14 Nov 2014 09:08:17 -0500
> Michael Orlitzky wrote:
>> Question 1: is it desirable to e.g. switch compilers, compile systemd,
>> and then switch back?
>
> This will horrifically break things like Portage's parallel build...
>
> No
On Fri, Nov 14, 2014 at 9:49 PM, Michael Palimaka wrote:
> On 14/11/14 15:01, Rich Freeman wrote:
>>
>> And I do apologize for piling on a bit - trying to get rid of @system
>> has been one of my soap box issues for a while. It really seems like
>> an ugly, if pract
On Wed, Nov 19, 2014 at 12:54 PM, hasufell wrote:
> On 11/19/2014 06:27 PM, Jauhien Piatlicki wrote:
>> On 11/19/2014 03:36 PM, hasufell wrote:
>>>
>>> In the end, I'm not sure if this is actually such a big problem. You can
>>> still use random ebuilds from random overlays and commit them straigh
On Wed, Nov 19, 2014 at 8:41 PM, Diego Elio Pettenò
wrote:
> On 31 October 2014 09:28, Diego Elio Pettenò wrote:
>> So who wants to pick up the pieces now? Because I'm almost pissed off
>> enough to turn down the tinderbox and give a big FU to Gentoo already.
>> https://bugs.gentoo.org/show_bug.c
On Wed, Nov 19, 2014 at 7:36 PM, hasufell wrote:
>
> But keep in mind that the core is supposed to shrink with this idea of a
> distributed model! So it would be less work to actually roll/tag
> releases than it would be right now (or even do that stuff in branches).
This doesn't really make the
On Tue, Nov 25, 2014 at 5:45 PM, Diego Elio Pettenò
wrote:
> Hi, did you end up running the script only for RESO/NEEDINFO or for all of
> them?
>
> If you have a chance to run it for every bug I will just turn down the
> S3 account afterwards.
Would it make sense to start logging the URLs that h
On Wed, Nov 26, 2014 at 4:21 PM, Tom Wijsman wrote:
> On Sat, 22 Nov 2014 00:34:33 + (UTC)
> Duncan <1i5t5.dun...@cox.net> wrote:
>
>> While it pains me to say this, unfortunately it looks like we have
>> another "toxic person" situation to deal with, with all the
>> implications that come wit
On Thu, Nov 27, 2014 at 4:22 AM, Luca Barbato wrote:
> On 26/11/14 22:52, Rich Freeman wrote:
>>
>> On Wed, Nov 26, 2014 at 4:21 PM, Tom Wijsman wrote:
>>>
>>> On Sat, 22 Nov 2014 00:34:33 + (UTC)
>>> Duncan <1i5t5.dun...@cox.net> wrote:
>&
On Mon, Dec 27, 2010 at 1:51 PM, Jeroen Roovers wrote:
> On Fri, 17 Dec 2010 23:31:28 +0100
> Maciej Mrozowski wrote:
>
> > Well, before I became developer, I had a quite unproductive
> > discussion on IRC with Jeroen on that matter (jer opting for status
> > quo and telling me I have no idea wh
On Tue, Dec 28, 2010 at 11:53 PM, Mike Frysinger wrote:
> please refrain from posting html to mailing lists
Apologies - just migrated to Gmail and didn't notice the obnoxious
default behavior...
Rich
On Fri, Dec 31, 2010 at 12:53 PM, Mike Frysinger wrote:
>
> personally, i dont see a problem here. what actual burden is there for
> continuing supporting EAPI 0/1 ? i dont think we should go around deprecating
> things for the pure fun of it.
> -mike
>
I tend to agree, unless of course the mai
On Sun, Jan 2, 2011 at 4:46 PM, Dale wrote:
> As a regular reader of gentoo-user, if someone has not updated in more than
> a year, we almost always recommend a re-install. Maybe save /etc, /home and
> the world file and then start from scratch on the rest. As a user since the
> 1.4 days, I woul
On Fri, Jan 7, 2011 at 10:39 AM, Lars Wendler wrote:
> Please pretty please read the elog messages when you update/install app-
> emulation/virtualbox for the first time after this package move. It contains
> important information!
Shouldn't this be announced in a news message, and not a posting
2011/1/7 Tomáš Chvátal :
> And news items are supposed to be done when something changes so
> drastically elog events does not sufice.
>
> elog "IMPORTANT!"
> elog "If you upgrade from app-emulation/virtualbox-ose make sure to run"
> elog "\"env-update\" as root and logout and relogin as the user y
On Wed, Jan 19, 2011 at 7:50 PM, Diego Elio Pettenò wrote:
> *PLEASE NOTE:* This is to be considered QA policy, so we're going to ask
> soon to enforce this.
Forward going? Or, should we go ahead and start retroactively
updating ebuilds that have mirror:// in them right now? Presumably
without
On Thu, Jan 20, 2011 at 3:38 PM, Fabian Groffen wrote:
> Like Jeroen, I don't think new package releases should be announced on
> these developer-related lists.
Tend to agree, at least in general. If a genkernel upgrade impacted
multiple teams/etc, such as requiring changes to install media, or
On Fri, Jan 21, 2011 at 11:00 AM, Luca Barbato wrote:
> "Yes, we all know that the history with the Infra team has been against
> this idea, but until there is a proper replacement for this handling,
> the Gentoo sources archive, we really shouldn't be putting the data in
> non-permanent locations
2011/1/28 Tomáš Chvátal :
> So draft we would like to have implemented as Glep update is this diff:
> http://dev.gentoo.org/~scarabeus/glep-0048.diff
>
> Please comment and help us improve the "english" of the whole document
> so it gets accepted :)
My only general comments are:
1. It makes sens
On Tue, Feb 8, 2011 at 7:03 AM, Markos Chandras wrote:
> I see what you are saying. However, the 6 months testing is far from
> what I have in mind.
I could see there being room for something in-between, but I share the
concerns of others that rolling releases are part of what makes
Gentoo, well,
On Feb 8, 2011 11:44 AM, "Donnie Berkholz" wrote:
>
> (With exceptions for security issues.)
Other than monitoring bugzilla, how does a Gentoo user even know that they
have a package pending a security update? It seems like glsa's lag
stabilization by a considerable timeframe.
I get the impress
On Tue, Feb 8, 2011 at 12:57 PM, Fabian Groffen wrote:
> On 08-02-2011 18:46:32 +0100, Andreas K. Huettel wrote:
>> > Other than monitoring bugzilla, how does a Gentoo user even know that they
>> > have a package pending a security update? It seems like glsa's lag
>> > stabilization by a consider
On Wed, Feb 9, 2011 at 9:08 AM, "Paweł Hajdan, Jr."
wrote:
> I think http://www.gentoo.org/security/en/vulnerability-policy.xml
> specifies the target delay, and also mentions temporary GLSAs.
> Unfortunately, that process does not seem to be followed due to general
> difficulty of drafting GLSAs
On Thu, Feb 10, 2011 at 6:44 PM, Markos Chandras wrote:
> Yes, I would definitely be interested in having some spare vms to run
> some automated tests etc. Probably other QA member would be interested
> as well
I'd be really interested in something that ends up as a howto on
automated testing / t
On Mon, Feb 14, 2011 at 1:00 PM, Pacho Ramos wrote:
> Please see attached news item for reviewing. Referred guide is still not
> committed as
> it still needs some work about evolution stuff that Gilles will provide soon.
Would it make sense to mention the timeline for stabilizing gnome? Is
it
On Mon, Feb 14, 2011 at 5:47 PM, Pacho Ramos wrote:
> My plans were to CC arches around Thursday or so
>
Sorry - I was thinking in the news item itself, and of course getting
the news item out a day or two before CCing arches...
On Tue, Feb 22, 2011 at 3:55 AM, Ulrich Mueller wrote:
>> On Tue, 22 Feb 2011, Mike Frysinger wrote:
>> that might disallow it for binaries, but it doesnt disallow it from
>> being used in ebuilds. same situation as binary kernel drivers --
>> make it the end user's problem.
>
> Why should we
On Tue, Feb 22, 2011 at 12:10 PM, Ulrich Mueller wrote:
> There's also a "sounds" local flag which generally means "install
> optional sound data". Maybe games-rpg/drascula should use this one
> instead?
I can vouch that eternal-lands-data uses the sound use flag in the
same way - the only differ
On Fri, Mar 4, 2011 at 6:46 PM, Alex Alexander wrote:
> Anyway, compilation on a modern system shouldn't take more than an
> hour. ~15-20 minutes on a quad i5.
Clearly your definition of modern doesn't include my server... :)
Just checked and the last build clocked in at 192 minutes. I need to
On Sat, Mar 5, 2011 at 5:00 AM, Nikos Chantziaras wrote:
> On 03/05/2011 04:41 AM, Rich Freeman wrote:
>> I need to
>> make sure I have /var/tmp/portage symlinked back to a non-tmpfs
>> location whenever I build it or else the system pretty-much dies from
>> a lack o
On Sat, Mar 5, 2011 at 5:21 AM, Dale wrote:
> It seems you correct the first time.
>
> http://en.wikipedia.org/wiki/Tmpfs
>
> I found the same examples in other paces as well. One is in the mount man
> page.
While this is drifting off-topic this is not the case. You can limit
the size of a tmpf
On Mon, Mar 7, 2011 at 4:32 PM, Fabian Groffen wrote:
> As outsider, I don't like to accept another certificate thing, just to
> view a bugtracker.
When you think about it, this is a defect with your browser, and not
so much with SSL itself.
Your browser generally doesn't complain about unauthen
On Mar 9, 2011 5:45 PM, "Petteri Räty" wrote:
> Have GLEPs in practice been sent to the forums? I think this requirement
> could be dropped and just have a single place for discussion.
It says either is fine, so I wouldn't call it a requirement.
However, a GLEP update warrants at least one post
On Fri, Mar 25, 2011 at 2:26 PM, Mike Frysinger wrote:
>> - keys are revoked [3]
>
> yes
>
To facilitate this, should we pick a preferred keyserver or two? Devs
of course are welcome to use others also, but if we're going to check
for revocations, we should specify where devs should upload them
On Sun, Mar 27, 2011 at 9:30 AM, Jeremy Olexa wrote:
> On 03/27/2011 02:47 AM, Nirbheek Chauhan wrote:
>>> On 03/26/2011 12:52 AM, Mike Frysinger (vapier) wrote:
>> I propose that we should be more aggressive about package.masking (for
>> removal) all maintainer-needed packages from the tree by do
On Mar 27, 2011 11:01 AM, "Tomáš Chvátal" wrote:
> And how exactly you want to track the level of failure for the package?
> Since nobody is watching them already we usually don't know how much
> they fail until somebody tries to emerge them from dev team or notify QA
> by adding as CC to bug...
On Sun, Mar 27, 2011 at 3:40 PM, Nirbheek Chauhan wrote:
> It's really simple:
>
> (a) If the package has plenty of users, there should be no problems
> finding a maintainer or a proxy-maintainer.
Uh, I guess that's why we are flooded with people wanting to be
devs... There are lots of high-use
On Sun, Mar 27, 2011 at 4:36 AM, Samuli Suominen wrote:
> USE="hal" is masked in base/use.mask, but unmasked for kde-base/solid
> and app-cdr/k3b in base/package.use.mask pending on KDE 4.6.x stabilization.
app-cdr/k3b (abridged):
--- k3b-2.0.2-r1.ebuild 2011/03/26 14:40:09 1.4
+++ k3b-2.0.2-
On Mon, Mar 28, 2011 at 7:25 AM, Rich Freeman wrote:
>
Apologies - did not take careful note of my headers.
Rich
On Sun, Mar 27, 2011 at 10:47 PM, Kumba wrote:
> 1. How can I revoke the old key? The revocation cert is probably on the
> same drive.
You can't. You need the private key to generate a revocation
certificate. The best you might be able to do is ask keyserver admins
to remove it manually, or tr
2011/3/28 Tomáš Chvátal :
> Shit happens as it is used to say,
As demonstrated by my clumsy reply... :)
> albeit for next time it might better
> rather than filling the bug fixing it yourself and just reporting it on
> - -dev :) So it gets fixed faster :)
Not if I test it properly (direct chang
1401 - 1500 of 2196 matches
Mail list logo
