Rubyinstaller devel - Aug 2009 - OT: FYI - Will be partially away the next days

Hey everybody,

Is not that I''m important to anyone or that my silence will raise the
fllod _why disappearing trick did.

Anyhow, wanted to let you know that I''ll be traveling a lot the next
few days and will take me longer to get back to anyone.

There are some pending things in my list that I would try to get done:

* Signed installers (got the cert)
* Integration of proper-openssl-2 branch.

While first one would be easy, it will have no impact until next
release, which perhaps is not going to happen soon.

The second one is more important, since it will solve the potential
conflicts we could have dealing with PostgreSQL libraries in the PATH.

I would appreciate if anyone can take a look to snaury fork and see
how it works or if something breaks :-D
(guess is on master branch now?)

Suffer from OCD is hard to overcome, so would like you guys help me out on it :)

Thanks in advance and will still checking the group while traveling,
but not so intensive as is now :(

Cheers!
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

On Fri, Aug 21, 2009 at 7:36 PM, Luis Lavena<luislavena at gmail.com>
wrote:
> I would appreciate if anyone can take a look to snaury fork and see
> how it works or if something breaks :-D
> (guess is on master branch now?)
No, it''s still a separate proper-openssl-2 branch.

I don''t quite like what I had to do in rake/extracttask.rb. While cp_r
does the job, unlike mv it''s pretty slow. I have this:
http://git.kitsu.ru/mine/df-ruby.git?a=blob;f=lib/df/fileutils.rb;h=f81dcb36b5e546d99839238b75358cd1d03a4a93;hb=be039169bbf35145d87d55cdb58c8cf58d5711d5,
but it patches FileUtils, which might be considered bad. :-/ Or maybe
we could do a simpler version of that, which doesn''t have to deal with
lists of sources, etc.

Or, maybe if we kept tags somewhere (like .mingw.extracted,
.msys.extracted, etc.), build system wouldn''t need to reextract
everything every time... and the issue would be almost moot.

Btw, using :force => true with FileUtils.mv is a really bad idea. All
it does is ignores any errors, and most likely that''s not what you
want. I''ve been bitten many times by that, when it couldn''t
move
something and just silently succeeded (e.g. immediately after ruby is
unpacked Kaspersky goes inspecting it, and mv fails O.o which causes
only much later in the build process, when directory ext or something
else is missing).

On Fri, Aug 21, 2009 at 1:01 PM, Alexey Borzenkov<snaury at gmail.com>
wrote:
> On Fri, Aug 21, 2009 at 7:36 PM, Luis Lavena<luislavena at gmail.com>
wrote:
>> I would appreciate if anyone can take a look to snaury fork and see
>> how it works or if something breaks :-D
>> (guess is on master branch now?)
>
> No, it''s still a separate proper-openssl-2 branch.
>
Cool.
> I don''t quite like what I had to do in rake/extracttask.rb. While
cp_r
> does the job, unlike mv it''s pretty slow. I have this:
>
http://git.kitsu.ru/mine/df-ruby.git?a=blob;f=lib/df/fileutils.rb;h=f81dcb36b5e546d99839238b75358cd1d03a4a93;hb=be039169bbf35145d87d55cdb58c8cf58d5711d5,
> but it patches FileUtils, which might be considered bad. :-/ Or maybe
> we could do a simpler version of that, which doesn''t have to deal
with
> lists of sources, etc.
>
> Or, maybe if we kept tags somewhere (like .mingw.extracted,
> .msys.extracted, etc.), build system wouldn''t need to reextract
> everything every time... and the issue would be almost moot.
>
What needs to be done is complete the new DSL branch, but I has been
so busy that commit time to it would be impossible.

The new format for recipes uses checkpoint files for the tasks and
treat packages individually, so if a source /origin for a file
download changed: it will download the files and extract them, since
the previous checkpoint file got invalidated.
> Btw, using :force => true with FileUtils.mv is a really bad idea. All
> it does is ignores any errors, and most likely that''s not what you
> want. I''ve been bitten many times by that, when it
couldn''t move
> something and just silently succeeded (e.g. immediately after ruby is
> unpacked Kaspersky goes inspecting it, and mv fails O.o which causes
> only much later in the build process, when directory ext or something
> else is missing).
I don''t remember the reasoning behind it actually, was over the Bazaar
repo, and don''t have it handy at work''s computer.

But I agree, it is bad, but got the job done at that time.

I''m going to send my proposal for the recipe to the list next week,
and would love your input and others in the list.

Once we settle on the format, I''m going to put the initial specs and
focus in converting existing messy rake task to something cleaner in a
recipe way.

Me sitting at the airport, having a sprite with ice thanks you for
your continuos feedback :)

Cheers!
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

On Fri, Aug 21, 2009 at 8:13 PM, Luis Lavena<luislavena at gmail.com>
wrote:
> What needs to be done is complete the new DSL branch, but I has been
> so busy that commit time to it would be impossible.
>
> The new format for recipes uses checkpoint files for the tasks and
> treat packages individually, so if a source /origin for a file
> download changed: it will download the files and extract them, since
> the previous checkpoint file got invalidated.
What I''d also like to see is checksum checking for download tasks.
Right now checksums are not checked, so you can never be sure that you
downloaded what you originally planned on downloading. Worse, when I
first tried building it, my connection somehow dropped in the middle
and one of msys-related files was only partially downloaded. Yet
somehow download task was thinking it succeeded and later extracting
it obviously failed (so I had to delete the corrupted file to
continue). Situations like this could be caught earlier if there was
checksum checking.
>> Btw, using :force => true with FileUtils.mv is a really bad idea.
All
>> it does is ignores any errors, and most likely that''s not what
you
>> want. I''ve been bitten many times by that, when it
couldn''t move
>> something and just silently succeeded (e.g. immediately after ruby is
>> unpacked Kaspersky goes inspecting it, and mv fails O.o which causes
>> only much later in the build process, when directory ext or something
>> else is missing).
> I don''t remember the reasoning behind it actually, was over the
Bazaar
> repo, and don''t have it handy at work''s computer.
Well, I can only guess that you might have been doing it because it
currently extracts stuff over and over again every time. And when
extracting ruby, for example, the moving out phase was obviously
failing, because target directories already exist.

I just pushed this change that implements mv_r without hacking FileUtils:

http://github.com/snaury/rubyinstaller/commit/397a4b61ed507aef06ed9e0591302428828c126c

Somehow it even feels more stable than my hackish FileUtils version.
> But I agree, it is bad, but got the job done at that time.
>
> I''m going to send my proposal for the recipe to the list next
week,
> and would love your input and others in the list.
>
> Once we settle on the format, I''m going to put the initial specs
and
> focus in converting existing messy rake task to something cleaner in a
> recipe way.
Cool, can''t wait for that! ;)
> Me sitting at the airport, having a sprite with ice thanks you for
> your continuos feedback :)
>
> Cheers!
Have a nice trip! :p

On Fri, Aug 21, 2009 at 6:55 PM, Alexey Borzenkov<snaury at gmail.com>
wrote:
> On Fri, Aug 21, 2009 at 8:13 PM, Luis Lavena<luislavena at gmail.com>
wrote:
>> What needs to be done is complete the new DSL branch, but I has been
>> so busy that commit time to it would be impossible.
>>
>> The new format for recipes uses checkpoint files for the tasks and
>> treat packages individually, so if a source /origin for a file
>> download changed: it will download the files and extract them, since
>> the previous checkpoint file got invalidated.
>
> What I''d also like to see is checksum checking for download tasks.
> Right now checksums are not checked, so you can never be sure that you
> downloaded what you originally planned on downloading. Worse, when I
> first tried building it, my connection somehow dropped in the middle
> and one of msys-related files was only partially downloaded. Yet
> somehow download task was thinking it succeeded and later extracting
> it obviously failed (so I had to delete the corrupted file to
> continue). Situations like this could be caught earlier if there was
> checksum checking.
>
I was considering the same, it is a flaw of the implementation that I
want to get fixed with the DSL implemention.

Please submit a Feature request with Build recipes as category at
RubyForge, so I keep track of it.
>>> Btw, using :force => true with FileUtils.mv is a really bad
idea. All
>>> it does is ignores any errors, and most likely that''s not
what you
>>> want. I''ve been bitten many times by that, when it
couldn''t move
>>> something and just silently succeeded (e.g. immediately after ruby
is
>>> unpacked Kaspersky goes inspecting it, and mv fails O.o which
causes
>>> only much later in the build process, when directory ext or
something
>>> else is missing).
>> I don''t remember the reasoning behind it actually, was over
the Bazaar
>> repo, and don''t have it handy at work''s computer.
>
> Well, I can only guess that you might have been doing it because it
> currently extracts stuff over and over again every time. And when
> extracting ruby, for example, the moving out phase was obviously
> failing, because target directories already exist.
>
> I just pushed this change that implements mv_r without hacking FileUtils:
>
>
http://github.com/snaury/rubyinstaller/commit/397a4b61ed507aef06ed9e0591302428828c126c
>
> Somehow it even feels more stable than my hackish FileUtils version.
>
Please test it from scratch and with previous checked out tools. Once
it works as you expected, send me the pull request for me to review
it.

Then, will merge those changes and give you commit rights, so no
longer need to work on your fork ;)

Cheers,

-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

On Tue, Aug 25, 2009 at 1:06 AM, Luis Lavena<luislavena at gmail.com>
wrote:
> Please test it from scratch and with previous checked out tools. Once
> it works as you expected, send me the pull request for me to review
> it.
Yes, it still works, just like four days ago when I pushed it. ;) I
added one new commit though, changing the way patch is called (-d
instead of cd with relative path calculation), nothing major.
> Then, will merge those changes and give you commit rights, so no
> longer need to work on your fork ;)
Please don''t, I prefer working on forks: more peer review, more The
Git Way, yadda yadda yadda.