On Fri, Feb 24, 2012 at 1:43 PM, Alexis Ballier wrote:
> moreover the && wont delete the lib if revdep-rebuild failed i think,
> so it should be even safer to copy/paste :)
Am I the only paranoid person who moves them rather than unlinking
them? Oh, if only btrfs were stable...
Rich
On Fri, Feb 24, 2012 at 8:06 PM, Richard Yao wrote:
> Have you tried ZFS?
Yes - but not terribly interested in doing that on linux. I do
appreciate that it can be done, but still lacks raid-z reshaping,
which means it isn't quite flexible enough.
> On 02/24/12 18:26, Duncan wrote:
>> FWIW, in t
On Fri, Feb 24, 2012 at 10:44 PM, Mike Gilbert wrote:
>
> I've been using btrfs exclusively for about 6 months, and I don't
> *think* I've lost anything... :)
>
>From what I've seen as long as you keep things simple, and don't have
heavy loads, you're at least reasonably likely to get by unscathe
On Sat, Feb 25, 2012 at 10:02 AM, Doug Goldstein wrote:
> FWIW, I'll second the ZFS > btrfs suggestion.
Oh, if you need a safe COW filesystem today I'd definitely recommend
ZFS over btrfs for sure, although I suspect the people who are most
likely to take this sort of advice are also the sort of
On Sat, Feb 25, 2012 at 3:52 PM, Richard Yao wrote:
> ZFSOnLinux performance tuning is not a priority either, but there have
> been a few patches and the performance is good. btrfs might one day
> outperform ZFS in terms of single disk performance, assuming that it
> does not already, but I questi
On Sat, Feb 25, 2012 at 4:56 PM, Richard Yao wrote:
> raidz has 3 varieties, which are single parity, double parity and
> triple parity. As for reshaping, ZFS is a logical volume manager. You
> can set and resize limits on ZFS datasets as you please.
That isn't my understanding as far as raidz re
On Sat, Feb 25, 2012 at 5:47 PM, Richard Yao wrote:
> If you have proper backups, you should be able to destroy the pool,
> make a new one and restore the backup. If you do not have backups,
> then I think there are more important things to consider than your
> ability to do this without them.
I
On Thu, Mar 8, 2012 at 11:51 AM, Ulrich Mueller wrote:
>> On Thu, 08 Mar 2012, Michael Orlitzky wrote:
>
>> There's also libbash now:
>
> Looks like complete overkill to me, considering the simple task at
> hand.
>
Plus, wasn't the whole point that we can't guarantee that the bash
installed o
On Fri, Mar 9, 2012 at 12:47 PM, Zac Medico wrote:
> Anyway, lets focus on our main goal, which is to decide on a way to
> obtain the EAPI _without_ sourcing the ebuild.
Agreed. Plus, an approach that either uses the filename or something
like a comment line is also going to be much more flexibl
On Sat, Mar 10, 2012 at 9:27 PM, William Hubbs wrote:
> here is the udev 181 unmasking news item.
>
> If all goes well, this will be committed to the tree on 3/14 UTC.
I guess this might be OK for unstable, but before this goes stable we
really need to improve the docs around this. As far as I
On Sat, Mar 10, 2012 at 10:28 PM, Luca Barbato wrote:
> I guess we could pour more effort in getting dracut more easy to use and/or
> try to figure out which are the items that should be moved to / and fix the
> remaining ones...
>
Well, I'm trying not to take sides in that war. Unless we want t
On Sun, Mar 11, 2012 at 9:28 AM, Patrick Lauer wrote:
> I'd deprecate eapi2 too, we don't need 5 flavours around when we
> effectively only want to support one (and eapi0 in a few places)
>
> I wouldn't mind having a deprecation timeline for eapi3 too (now +6
> months maybe?), but there's no need
On Sun, Mar 11, 2012 at 12:18 PM, Chí-Thanh Christopher Nguyễn
wrote:
> Assume a new version 13.37 of your package manager drops EAPI=1 support.
> So package-manager-13.37.ebuild checks in pkg_pretend() if any EAPI=1
> package is installed on the system. If yes, then it aborts, telling the
> user
On Sun, Mar 11, 2012 at 8:15 PM, Francesco Riosa wrote:
> To be able to upgrade a gentoo installation as old as five years is
> interesting and valuable but require an effort that has yet to be
> made.
I suspect it shouldn't be difficult IF you have access to a binary
package respository for the
On Sun, Mar 11, 2012 at 10:03 PM, Brian Harring wrote:
> Pragmatic reality, the eapi function actually would work fine. As
> pointed out elsewhere, bash parses as it goes- which isn't going to
> change.
Unless the ebuild isn't written in bash...
How do you source the ebuild if you don't know wh
On Sun, Mar 11, 2012 at 7:15 PM, William Hubbs wrote:
>
> I was thinking of another news item once we are ready to go stable.
>
> What do you think?
>
I think that makes the most sense. That news item can include links
to the documentation that gets written over the next few months.
Rich
On Mon, Mar 12, 2012 at 6:12 AM, Kent Fredric wrote:
>
> There's the obvious case of compiled-binaries where that might not be
> possible, but thats definately strawman stuff and I wouldn't support
> that sort of nonsense anyway. Compiled binaries for ebuilds can gtfo.
>
Why do I feel like a simi
On Mon, Mar 12, 2012 at 11:59 AM, Ciaran McCreesh
wrote:
> On Tue, 13 Mar 2012 04:57:04 +1300
> Kent Fredric wrote:
>> I think this notion should be concluded before we continue debating as
>> to how best to implement EAPI declarations.
>>
>> Is it really so fixed that ".ebuild" will only ever be
On Mon, Mar 12, 2012 at 1:01 PM, Zac Medico wrote:
> It would be very fragile without the sanity check / feedback mechanism
> that's already been suggested.
Another obvious check is to have repoman run a grep with the regexp
and give an error if there is not exactly one match.
Rich
On Mon, Mar 12, 2012 at 1:46 PM, Zac Medico wrote:
> If we want to handle every possible screwup, including stray EAPI
> assignments inside inherited eclasses, we still need to compare the
> probed value to the value that's obtained from bash.
Well, I wasn't intending to suggest that the repoman
On Tue, Mar 13, 2012 at 2:29 AM, Richard Yao wrote:
> To make XML a viable substitute for bash, you will need to implement a
> turing complete language in XML, which should probably preclude its use
> in ebuilds. You would likely have better luck with a functional
> programming language, although
On Tue, Mar 13, 2012 at 8:20 PM, Joshua Kinard wrote:
> The trend now seems to be to modularize everything these days, even stuff
> like the core disk drivers, then build those core modules into an initramfs
> that the kernel cherrypicks from at boot. That's the perception, anyways,
> and one whi
On Tue, Mar 13, 2012 at 8:29 PM, Joshua Kinard wrote:
>
> My contention is that I shouldn't need an initramfs loaded into my kernel to
> get my system into a minimally-usable state. I've been running separate
> /usr setups for 10+ years, and only now, such a setup breaks, hence my beef
> with Fed
On Wed, Mar 14, 2012 at 1:29 PM, Zac Medico wrote:
> On 03/14/2012 10:11 AM, Maxim Kammerer wrote:
>> What's wrong with:
>> * having an "early mounts" list file
>> * having an "early modules" list file
>> * init system in early boot (e.g., OpenRC in init.sh) loading "early
>> modules" and mo
On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao wrote:
>
> I proposed a way that this could work with no effort on the part of the
> Gentoo developers in one of my earlier emails:
>
Then go ahead and make it happen. If as you say no dev participation
is needed there is nothing Gentoo needs to do to
On Thu, Mar 15, 2012 at 7:04 AM, Joshua Kinard wrote:
> This does lead me to wonder if a light-weight udev could exist that lacks
> half or more of the functionality of the current udev. I'll be honest, I've
> only edited my udev rules file once, and that was only when I installed a
> Sun Happy M
On Thu, Mar 15, 2012 at 10:42 AM, Greg KH wrote:
>
> Why not use the links in /dev/serial/ which are there for this specific
> reason?
>
# ls -l /dev/serial
ls: cannot access /dev/serial: No such file or directory
Something in a newer version of udev perhaps? Or would my defining my
own symlink
On Thu, Mar 15, 2012 at 2:28 PM, Ulrich Mueller wrote:
> The gentoo-news repository has moved from subversion to git some time
> ago. New news items should be committed to git only, because the
> master rsync doesn't pull from the svn repository any more.
>
Is there a link to the repository anywh
On Thu, Mar 15, 2012 at 3:17 PM, Greg KH wrote:
> On Thu, Mar 15, 2012 at 03:04:36PM -0400, Rich Freeman wrote:
>> # ls -l /dev/serial
>> ls: cannot access /dev/serial: No such file or directory
>
> Do you have your serial device plugged in? If not, it will not show up.
>
On Fri, Mar 16, 2012 at 8:49 AM, Christoph Niethammer
wrote:
> Here the euse command is realy handy. :-)
> However the sysfs USE flag is still hiding its documentation.
> So lets see if this is a bug or a feature. ;-)
Yup, euse is helpful, or you can grep /usr/portage/profiles/use.*
(including th
On Sun, Mar 18, 2012 at 3:23 AM, Ralph Sennhauser wrote:
> The ebuild extensions for GLEP 55
> would likely always be ebuild- as integers are reserved for
> future use by Gentoo.
Looking at GLEP 55 the proposal was ebuild- - not
ebuild-. I don't believe there is any restriction that EAPIs
be int
On Wed, Mar 21, 2012 at 10:34 AM, Richard Yao wrote:
> On 03/21/12 10:18, Justin wrote:
>> I will not extract part of the software, e.g. subroutines, for use in
>> other contexts without permission of the author.
>
> Portage could be considered to be one of these contexts.
Unless portage is just
On Tue, Mar 27, 2012 at 2:34 PM, Alexandre Rostovtsev
> The partitioning scheme is something that the user needs to decide on
> *before* getting Gentoo up and running. After the user had finished
> installing the operating system, it's too late to inform him about the
> advantages of a separate /u
On Wed, Mar 28, 2012 at 3:16 AM, Brian Dolbec wrote:
> On Tue, 2012-03-27 at 19:16 +0100, Ciaran McCreesh wrote:
>> But that's ok, because extensive studies have shown that the only possible
>> reasons for putting /usr/portage on its own partition are historical,
>> since everyone has an SSD now.
On Wed, Mar 28, 2012 at 10:59 AM, Richard Yao wrote:
> On 03/28/12 03:16, Brian Dolbec wrote:
>> On Tue, 2012-03-27 at 19:16 +0100, Ciaran McCreesh wrote:
>>> But that's ok, because extensive studies have shown that the only possible
>>> reasons for putting /usr/portage on its own partition are hi
On Wed, Mar 28, 2012 at 2:53 PM, Christoph Mende wrote:
>
> I believe it's /var/lib/. Here's what FHS says:
> /var/cache is intended for cached data from applications. Such data is
> locally generated as a result of time-consuming I/O or calculation.
> The application must be able to regenerate or
On Fri, Mar 30, 2012 at 2:47 PM, Ulrich Mueller wrote:
> Ebuilds in the Portage tree must be licensed under the GPL. This is
> part of the Gentoo Social Contract [1], so I guess it won't change
> anytime soon.
>
> And IMHO, we would be ill-advised to allow different licenses for
> ebuilds in the t
On Sat, Mar 31, 2012 at 7:44 AM, Samuli Suominen wrote:
> (or hand me powers to remove people from ML :-)
>
That sounds like a great idea. We could create a code of conduct, and
then designate individuals to enforce it. Maybe we should call them
proctors:
http://www.gentoo.org/proj/en/council/c
On Sun, Apr 8, 2012 at 6:04 PM, Greg KH wrote:
> On Sun, Apr 08, 2012 at 04:30:01PM +0200, Ulrich Mueller wrote:
>> The council has voted in favour of a separate /usr being supported
>> (5 yes, 1 no vote).
>
> What?
Perhaps the council should be the ones to clarify, but I think the
vote only was
On Tue, Apr 10, 2012 at 3:38 PM, Mike Frysinger wrote:
>
> i don't see a problem here. although this is something that you'd prob want
> to post to the trustees and let them make a decision.
> -mike
>
This is a bit of a stale thread. This particular package was modified
to remove the SRC_URI, s
On Tue, Apr 10, 2012 at 10:28 PM, Steven J Long
wrote:
> As for the burden of ensuring that binaries installed to /{s,}bin don't link
> to libs in /usr, why not just automate a QA check for that, and let
> developers decide whether a fix is necessary? After all, core packages that
> do that even w
On Wed, Apr 11, 2012 at 11:09 AM, Steven J Long
wrote:
> That might be true for some Linux-only packages, but I really find it hard
> to believe that any upstream targetting more than one OS (just adding a BSD
> is enough) with software that could be considered critical (I for one would
> include
On Wed, Apr 11, 2012 at 3:53 PM, William Hubbs wrote:
> To allay any fears of that happening, I have opened a tracker [1] for
> issues which need to be resolved before newer udevs can go stable.
>
Probably wouldn't hurt for the initramfs maintainers to open a
stablization tracking bug for whateve
On Sat, Apr 21, 2012 at 10:43 PM, Steven J Long
wrote:
> The Council has voted that Gentoo continue to support that subset, without
> an initramfs.
Citation, please?
Rich
On Tue, Apr 24, 2012 at 1:32 PM, Mike Frysinger wrote:
> it's also a bit of a speed issue. i often want to look at what flags get used
> across the tree. what's faster: loading + parsing 15000 xml files, or loading
> 1 file ? shifting it to metadata/ as a cache of all the xml files is probably
>
On Fri, Apr 27, 2012 at 9:45 AM, Amadeusz Żołnowski wrote:
> Excerpts from Duncan's message of 2012-04-27 15:38:20 +0200:
>> No distribution allowed. You're going to be doing restrict=mirror,
>> correct?
>
> Why RESTRICT=mirror? I'd put RESTRICT=fetch, actually.
>
I don't see much point in using
On Fri, Apr 27, 2012 at 7:35 AM, Chí-Thanh Christopher Nguyễn
wrote:
> I agree that the ~arch ebuilds should be tested in the same
> configuration in which they will end up in arch. However in this case,
> the possible configurations for arch are a subset of those in ~arch, so
> the testing covers
On Fri, Apr 27, 2012 at 10:54 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> Tho FWIW I think restrict=fetch applies to stuff like cd/dvd-based game
> data as well, where the agreement is on the cd not a website, but still
> requires specific click-thru.
I think the real determiner should almost alway
On Fri, Apr 27, 2012 at 11:33 AM, Amadeusz Żołnowski wrote:
>
> And this is probably the case when user has to accept a license on the
> website. This is URL for zip archive of yEd-3.9.1:
>
> http://www.yworks.com/en/products_download.php?file=yEd-3.9.1.zip
>
> It directs to website with license
On Fri, Apr 27, 2012 at 2:04 PM, Nikos Chantziaras wrote:
> Didn't the user already accept the license by putting it in ACCEPT_LICENSE?
> If not, portage will not download it.
>
Well, I'd argue that it is impossible to "accept a license" in the
first place. It is possible to agree to a contract
On Sat, Apr 28, 2012 at 2:53 PM, Alec Warner wrote:
> That doesn't mean you didn't / cannot accept, merely that some (all?)
> provisions are likely unenforceable in a court of law. I don't think
> EULAs have been ruled illegal yet.
I doubt that my proclamation that you aren't allowed to eat break
On Mon, Apr 30, 2012 at 4:05 AM, Tony "Chainsaw" Vroon
wrote:
> Binaries that are essential for system boot, and must be available in
> single user mode go in /bin and /sbin, with their libraries in /lib.
> This allows for /usr to be:
> 1) marked read-only for NFS mounts, which some of us rely on
On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger wrote:
> On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>> doing it wrong. I don't like how Google develops Android in the dark,
>> or that they bundle 1GB of third-party stuff in their Chromium source
>> and distri
On Thu, May 3, 2012 at 5:34 AM, "Paweł Hajdan, Jr."
wrote:
>
> Right, and the source tarball is ~175 MB. It's not perfect, but it's
> also far from 1 GB. The bundled libraries are included in the tarball.
I was thinking about the unpacked size - which is 1001M according to
du for chromium-18.0.10
On Fri, May 4, 2012 at 9:50 PM, Chí-Thanh Christopher Nguyễn
wrote:
> I'd say that Android is an operating system based on Linux. It is not
> 'the Linux "stack"'.
> I think he was wondering whether the lock-in between dbus, udev and the
> Linux kernel will reach proportions where they will be dist
On Sat, May 5, 2012 at 3:55 PM, Dale wrote:
> Jesus Rivero (Neurogeek) wrote:
>> I don't like this change much. There are valid use cases for an ldap use
>> flag in the desktop profile that could break easily with this change.
>>
There are valid use cases for every USE flag in portage, otherwise
On Sun, May 6, 2012 at 5:37 AM, Michał Górny wrote:
>
> I don't think even heavyweight DE/WM usually needs ldap...
>
Tend to agree. I don't think we want to create a new profile every
time we want to change one of the flags.
Some other questionable ones:
emboss - Adds support for the European M
On Mon, May 7, 2012 at 7:17 PM, Walter Dnes wrote:
> There's a "server" profile which could be the answer.
I've never seen that as being a terribly useful profile. Servers tend
to be very minimal configurations. Maybe if we ever ripped sshd out
of the default profile we might put it there, but
On Wed, May 9, 2012 at 9:08 PM, Patrick Lauer wrote:
> On 05/10/12 06:36, Greg KH wrote:
>> On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote:
>>> Please stop throwing lennartware at people. FailAudio has been enough,
>>> thanks.
>> The use of these terms is both rude and totally un
On Sat, May 12, 2012 at 6:34 AM, "Paweł Hajdan, Jr."
wrote:
> The idea is that if you only fix in ~arch, you risk a serious and
> _known_ regression in stable, which could be easily avoided.
How can you have a regression in stable if stable has the bug already?
A regression is when you have a st
On Sat, May 12, 2012 at 4:01 PM, "Paweł Hajdan, Jr."
wrote:
> Agreed. I'm talking about compile errors or crashes here. I've really
> seen arches stabilizing packages with known problems, just having closed
> bugs because "the fix is in ~arch".
We might already be on the same page, but I think th
On Wed, May 16, 2012 at 5:02 AM, Fabio Erculiani wrote:
> I implemented this feature in Entropy long time ago (2009 iirc) and
> enabled it by default as well.
> We never had a single issue. Users seem quite happy about it.
>
This is also the default behavior with the cfg-update alternative to
dis
On Wed, May 23, 2012 at 4:02 AM, Samuli Suominen wrote:
> On 05/23/2012 05:36 AM, Ryan Hill wrote:
>> One person doesn't do entries. OMG let's remove it!
>>
>
> absolutely because inconsitency renderess the file useless
>
Well, for now the solution is to enforce following policy.
For the future
On Wed, May 23, 2012 at 10:43 AM, Anthony G. Basile wrote:
>
> Looks like the bloodbath begins. I too am in favor of killing cvs.
Please, let it die. I'll miss my scripts, but I'll gladly deal with
that over whatever breakage comes along every time some cvs plugin
messes up the tree, or we can'
On Wed, May 23, 2012 at 1:22 PM, Alexey Shvetsov wrote:
>
> That isnt true =) you can commit from shallow clone if and only if original
> repo doesnt have a branching and merging points before and after shallow
> clone point respectively
>
Is that going to be a practical condition to maintain?
On Wed, May 23, 2012 at 4:00 PM, Ezequiel Garcia wrote:
> On Wed, May 23, 2012 at 4:37 PM, Arun Raghavan
> wrote:
>> I, for one, think we should stay with CVS and leave all this git
>> Linusware to the new-fangled Fedora kids with their fancy init systems
>> and tight coupling. CVS was good enou
On Thu, May 24, 2012 at 11:02 AM, Ralph Sennhauser wrote:
> Can we keep the master on Gentoo hardware please.
>
> Also, there still should be a bug at b.g.o and git format-patch works
> just fine for that. Maybe it's only github now but how many places is a
> developer supposed to monitor?
I'm ac
On Thu, May 24, 2012 at 6:01 PM, Dan Douglas wrote:
> But ok it's a good point. Github isn't a good central point of contact. People
> have to use their discression. It's just uncommon these days for a project as
> big as Gentoo to have ultra-centralized corporate-style procedures where
> everythi
On Fri, May 25, 2012 at 11:23 PM, Ryan Hill wrote:
> Some projects are territorial. Games is one. I imagine adding something
> to kde, gnome, or xfce categories without contacting those guys would get you
> an email. If in doubt I usually file a bug when I'm adding a package and CC
> them. If
On Mon, May 28, 2012 at 9:09 PM, Maxim Kammerer wrote:
> Ditto, ~2 years with regular full @world rebuild.
>
Yup, been years since the last time I even saw a bug for this.
Probably wouldn't hurt to announce in news if it will impact existing
users. I doubt anybody would actually remove the port
On Tue, May 29, 2012 at 10:11 AM, Michał Górny wrote:
>
> Wouldn't that break users who sync using a regular user? And then break
> again, and again every time portage is merged?
Yup, unless that regular user is the same one used for userpriv (if
I'm correctly understanding the problem that you'r
On Tue, May 29, 2012 at 10:57 AM, hasufell wrote:
> I am against too many defaults. It's documented and people can
> activate it.
> I'm already annoyed by pre-set stuff like "cups" in
> releases/make.defaults.
While universal agreement is a bit much to hope for, I just wanted to
point out that fe
On Sat, May 26, 2012 at 12:18 PM, Alexey Shvetsov wrote:
> Since most of us want "clean cut" solution so i will close bug #333699 as
> WONTFIX
Along these lines, I'm looking at 333531 (the git migration tracker),
and it seems like there isn't actually much to do:
333685 - Seems like no action, a
On Wed, May 30, 2012 at 6:16 AM, Dirkjan Ochtman wrote:
> Yeah... this is why I was asking about access to infra to test the
> conversion; so far, I haven't had any replies, though.
>
A mock conversion would probably help with creating
procedures/docs/etc as well. It is nice to say that we're "j
On Thu, May 31, 2012 at 12:49 PM, Robin H. Johnson wrote:
> 1.
> Discussion on merge policy. Originally I thought we would disallow merge
> commits, so that we would get a cleaner history. However, it turns out that if
> the repo ends up being pushed to different places with slightly different
> h
On Thu, May 31, 2012 at 3:13 PM, Robin H. Johnson wrote:
> - You have a commit, that you want to put into the Gentoo tree.
> - You have already pushed it to your github, signed
> - It needs to be merged/rebased so that it applies on the Gentoo tree.
> - If you force it to be a rebase so it applies
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 to throw away history (which is either
good or bad based on your perspective).
So, if 14 devs spend 3 years
On Thu, May 31, 2012 at 5:52 PM, Kent Fredric wrote:
> Just I haven't worked out what happens when the SHA1 of the 'parent'
> header changes, which *will* change if the rebase is anything other
> than a fast-forward.
>
> If that SHA1 changes, the gpg signature will surely fail?
Rebasing doesn't m
On Fri, Jun 1, 2012 at 12:05 AM, Michał Górny wrote:
> Yes, it isn't but such kind of work flow was presented in the message I
> replied to.
Yup, I wasn't aware that when rebasing you have the option to squash
commits or not. They all get rewritten as if they were applied to the
current head in
On Fri, Jun 1, 2012 at 12:55 AM, Kent Fredric wrote:
>
> Hmm, thats annoying. Almost makes me wish it was the trees that were
> signed, not the commits.
I think it is the tree that is signed, but that changes too.
Rebasing re-applies the same diff to the new head to give you a new
set of commits
On Fri, Jun 1, 2012 at 7:23 AM, Kent Fredric wrote:
>
> Nope, at least not as far as I can tell, and I just implemented commit
> signature verification >_>
I've been trying to find an example of a signed commit, but can't find
one anywhere, so it is hard to tell what it is doing without going
thr
On Fri, Jun 1, 2012 at 11:12 AM, Andreas K. Huettel
wrote:
> Now, does the "signed data" also contain the parent sha?
>
So, I was working on a lengthy email which now would be fairly
repetitive of what Kent posted.
Suffice it to say I managed to rip out a commit from the kde overlay,
deflate it,
On Fri, Jun 1, 2012 at 9:25 AM, Nicolas Sebrecht wrote:
> So, like explained before your concern is clearly out of the current
> discussion. Importing commit history from Overlays is not supported and
> will probably never be. Gentoo doesn't forces (and doesn't want to)
> overlays maintainers to u
On Fri, Jun 1, 2012 at 11:36 AM, Andreas K. Huettel
wrote:
>> On 2 June 2012 03:12, Andreas K. Huettel wrote:
>> Yes. Which basically means, you *cannot* have both
>>
>> a) rebase only merges
>> and
>> b) every commit must be signed
>>
>> as policies.
>>
>
> I would say that this is a very strong
On Fri, Jun 1, 2012 at 12:33 PM, Robin H. Johnson wrote:
> What about overlay repositories that elect to be a branch of the main
> tree via git?
>
> Do we call that forbidden usage?
I think that branches off of the main tree are mainly going to be
useful for more eclass/profile/etc-related work.
On Fri, Jun 1, 2012 at 4:49 PM, Michael Weber wrote:
>
> Cloning the repo [1] takes 200seconds on 8cores (it's 2GB of data and
> 22 minutes of 3.4GHz cpus).
>
As others have pointed out, probably the best way to bootstrap this is
to offer tarballs of a shallow repository and a full repository.
Pe
On Sat, Jun 2, 2012 at 12:04 AM, Robin H. Johnson wrote:
> please look up git-bundle before suggesting things like tarballs of
> repos/checkouts.
>
Looks useful. Wasn't aware that a bundle was something other than a tarball.
We'll probably need to spell out the preferred process in the docs,
an
On Sat, Jun 2, 2012 at 8:03 AM, Dirkjan Ochtman wrote:
> On Sat, Jun 2, 2012 at 12:59 PM, Rich Freeman wrote:
>> It appears that devs will have to add the remote for the live
>> repository after they've cloned the bundle - otherwise they'll just
>> keep pulling
On Sun, Jun 3, 2012 at 2:21 PM, Dirkjan Ochtman wrote:
> That makes a lot of sense. There are probably a bunch of
> projects/teams where having their own branches makes some amount of
> sense; but we should really try the free-for-all at first.
So, it sounds like we have a migrated tree already.
On Mon, Jun 4, 2012 at 2:50 AM, Dirkjan Ochtman wrote:
> On Sun, Jun 3, 2012 at 9:35 PM, Andreas K. Huettel
> wrote:
>> However, then the "committer" of the contributed commits before the merge is
>> then the user, I guess?
>>
>> (The rule meaning as suggested by Robin
>>> - if you include a com
On Mon, Jun 4, 2012 at 2:48 AM, Dirkjan Ochtman wrote:
> IMO we should try to be cutting down barriers from the git migration,
> not throwing up more. The process has taken long enough already; the
> desire to control everything about the migration is part of why it's
> taken so long.
Fair enough
On Mon, Jun 4, 2012 at 8:45 AM, Dirkjan Ochtman wrote:
>
> Well, it doesn't seem like a big deal IF there's an explicit merge
> commit that's signed by a dev.
I'm not sure about that. If you were verifying a tree, how would you
identify which commits were merged in by what dev, using an automate
On Mon, Jun 4, 2012 at 9:48 AM, Dirkjan Ochtman wrote:
>
> You simply walk the tree from root to tip. When you encounter an
> unsigned changeset, the nearest signed descendant is responsible for
> merging that changeset.
>
How do you KNOW that the nearest signed descendant actually merged it?
Ho
On Mon, Jun 4, 2012 at 10:26 AM, Dirkjan Ochtman wrote:
> On Mon, Jun 4, 2012 at 4:18 PM, Rich Freeman wrote:
>> How do you KNOW that the nearest signed descendant actually merged it?
>>
>> How do you know it wasn't added by a hacker?
>
> Because then the
On Mon, Jun 4, 2012 at 11:02 AM, Dirkjan Ochtman wrote:
> If the tree was bad before you pushed, then it's not your fault the
> tree is bad. You're only responsible for the commits you bring into
> the tree, so if you're merging contributor's unsigned changesets, you
> merge them with a signature
On Mon, Jun 4, 2012 at 12:19 PM, Dirkjan Ochtman wrote:
> So to prevent your scenario, we'd
> have to get everyone to check the signature of the tip of tree they
> pulled before committing/merging.
How can we be sure this has happened?
This is the problem with signed manifests today. I can sign
On Mon, Jun 4, 2012 at 3:10 PM, Brian Harring wrote:
> One thing people need to keep in mind here is that when you sign the
> commit, you're signing off on the history implicitly. Directly
> addressing freeman's comment about "people sign the manifest but don't
> look at what they're signing", wh
On Mon, Jun 4, 2012 at 4:41 PM, Brian Harring wrote:
>
> If that doesn't answer your question/concerns, be more explicit
> please.
How about a scenario:
1. Gentoo dev commits a bunch of stuff to the tree. Top of tree is signed.
2. Hacker commits something to the tree. Top of tree is not sign
On Tue, Jun 5, 2012 at 2:50 AM, Michał Górny wrote:
> On Mon, 4 Jun 2012 16:57:42 -0400
> Rich Freeman wrote:
>
>> If you go back and look at the tree you see a bunch of signed and
>> unsigned commits. How do you easily detect how the unsigned ones got
>> there (vi
On Fri, Jun 8, 2012 at 7:01 AM, W. Trevor King wrote:
> When the breach is discovered, you can then isolate the dev (or devs)
> who implicitly signed the hack (2) by pulling the ToT without checking
> for a valid signature (3). Then you yell at them for sloppy security,
> and tell them to install
1 - 100 of 2195 matches
Mail list logo
