| |
| |
| |
|
Page: 1 2 3 4 5
Comments:
<0> NOTE: 1h to read-only.
<0> actually i don't wear watches
<0> can't have anything around my wrist
<0> feels uncomfortable
<1> so that wristmounted pda thingy isn't for you
<0> definitly not. If anything, I'd use a startrek ng communicator thing
<2> mickeyl: did you happen to see the discussion about openzaurus-unstable becoming an 'insane' configuration for bitbake, after your recent config changes? was i right to conclude that you did so intentionally, with the point being to force people to realize they're dealing with an "unsupported" configuration?
<0> zwelch: no, it was an accidant
<2> okay :)
<0> which i fixed by giving sanity.bbcl*** a second chance to succeed in verifying DISTRO
<2> well, i gave you the benefit of the doubt :)
<0> :)
<2> so i can probably kill my local sanity.conf now, right?
<0> .conf or bbcl***?
<2> well, with an 'insane' config, bb tells you to touch sanity.conf
<0> oh
<0> never did that :)
<2> i touched build/conf/sanity.conf, and *poof* it started working again
<2> yeah, it took me an hour just to read the error it was giving me
<1> hah
<2> in point of fact, it raises an exception caused by not importing sys.exit
<0> i fixed that in bitbake as well :D
<2> the exception has the effect on my brain to mask the informative error message it tried to print
<1> 12:40 <1>: (not that our devs excel in reading error messages....)
<0> *nod* tracebacks are not for users...
<2> sweet :)
<0> users being developers in OE, but anyway. I prefer nice errors
<2> koen: i read them... but as mickeyl just said, it helps to give users the proper message
<1> zwelch: I made that comment this afternoon about people complaining about not being able to push after we go read-only
<2> it's for what, a week?
<1> something like that
<2> incidentally, i don't remember seeing one when i grabbed my copy, but what are the odds that someone will seed a torrent to distribute converted DB?
<2> or was i mistaken in the impression that it will be necessary to 'start fresh' in that way?
<1> a torrent would be much of an improvement, since we'd have daily snapshots
<1> so you'd need to switch to a new torrent everyday
<2> i'm thinking more about the initial re-launch
<3> coredump org.oe.oz354x * redd003af... /conf/machine/poodle-2.6.conf: poodle-2.6.conf: Add alsa-settings
<2> i.e. immediately post-migration
<2> ... when everyone will want a copy, and when the p2p effect will be most effective
<2> also, if pulls are that much faster, it may be more economical on bandwidth to publish less frequently than a daily snapshot
<1> we have bandwidth to spare
<2> heh, then it doesn't matter much
<1> 2x 100Mbit boxen with unlimited traffic
<2> anyway, i was just thinking outloud. y'all seem to have put a lot of thought into this migration, and i'm sure it will go smoothly
<2> does OE have boxes at the OSL?
<2> OSUOSL, that is
<4> hey, are you planning on generating stats for migration downloads? it could tell how much ppl uses oe actively nowadays.
<1> no, at utwente.nl and strato.de
<2> ah
<2> well, i can get the project hosting at the OSL, if necessary
<2> i can probably toss a server in along with it
<1> that would be nice as a long term plan
<2> well, the offer is here while i am ;)
<2> but they are easy to approach directly too
<2> anyway, thanks for the feedback; i'm off to play my mandolin
<5> why a week? I did a complex CVS->Svn in under a day
<6> Luke-Jr: and how did you verify everything worked as expected?
<0> see migrationplan
<6> We create a schedule, we announce it X times
<6> and then someone always knows better
<5> zecke: I did all that before the actual migration
<1> and someone always complains
<1> YOU ALL ****
<6> Luke-Jr: ah you tested the result
<6> Luke-Jr: before creating it?
<6> :)
<5> I simply updated the result for the actual migration
<6> just kidding :)
<5> which reduced testing to a very small period of time
<6> Luke-Jr: Why does it take so long?
<5> ?
<6> Well: a) the rosterify itself takes 8 hours
<5> O.O
<6> b) testing viewmtn, mailing lists, checking stuff out, irc bots
<1> ah yes
<6> takes human resources, I do not know if they are allocatable
<5> 'b' could have occurred on a copy prior to the actual migration =p
<1> I should diff viewmtn against mainline to see how much I changed
<6> then we might stumble a bug in mtn that delays another X time items
<6> Luke-Jr: well, testing a real system on real world load will always be different
<5> only the load amounts
<0> koen: you're here during the complete migration phase?
<5> why not have the mtn server cache a value for 'has had signature verified' and let clients skip verifying them when it's already been done? :p
<6> Luke-Jr: feel free to do the migration for us within a day
<6> Luke-Jr: I would be glad if things work out more soon
<1> mickeyl: as a said, I'm staying out of the migration biz
<5> zecke: my mtn usage is currently merely pull && update
<0> koen: hmm.... my vacation starts on 20th, so i'm afraid i will have to miss the last two days.
<0> koen: will we have a read-only svn/cvs mirror soonish after the migration?
<1> if
<1> a) people want one
<1> b) someone steps up to maintain it
<5> I want a read-write Svn mirror!
<0> a) absolutely
<5> :)
<1> the script is in ~/monotone/
<0> b) shouldn't be more than a hourly cronjob if we're satisfied with 1h lag?
<1> heh
<1> it's cvs remember
<1> concurrent breakage system
<0> hehe
<6> mickeyl: higher lag
<0> how much?
<0> anything less than 24h would do imo
<6> 23:59 ;)
<0> fair enough
<0> i bet it will make many people happy, albeit all lurkers
<1> mickeyl: or make it weekly
<1> mickeyl: we do have to encourage using the real thing
<6> mickeyl: well, lurkers will demand a working ci
<6> anyway I won't participate in such discussions
<0> that's true. although i think daily sync would be a good compromise
<0> heh, you can't all stay out of the decisions
<1> people will always complain
<0> otherwise I just decide
<0> :D
<1> and I'm too fed up to cater them
<6> mickeyl: then I can atleast complain
<0> :D
<6> Luke-Jr: I would really welcome help on the migration
<6> Luke-Jr: you could update viewmtn patches, etc...
<6> Luke-Jr: the current migration plan is the most pessimist estimation I could create
<6> Luke-Jr: I didn't count on anyone to help, so if you want to ***is, you are very welcome
<5> hm
<5> well, if you want to mail me the current patched viewmtn, I'll look into it ;)
<5> php?
<6> koen: can we?
<1> zecke: sure, tar up ~/website/viewmtn/
<6> eek
<6> 185 in graphs
<1> and exclude graphs/
<5> lol
<6> hmm where may I put it?
<5> pipe it to mail? ;p
<1> iirc the biggest changes are to html.py for the OE look and feel
<6> Luke-Jr: handhelds.org/~zecke/viewmtn.tar.bz2
<5> a55778c9b4e11e5665d283aeb711265a
<5> ?
<6> 602ed5196d0ca6782c8b0d1ec5522dbc86cf8f84
<6> as sha1
<6> but your md5 sum matches as well
Return to
#oe
or
Go to some related
logs:
find out centos version
ubuntu cannot open resource for writing
apt-get cannot find build-essentials
verlihub connection to mysql server failed access denied
mongolian custard
python deepprint
it's not owned by LDAP
#centos
#javascript
#linuxhelp
|
|