Luis Lavena
2009-Aug-21 15:36 UTC
[Rubyinstaller-devel] 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
Alexey Borzenkov
2009-Aug-21 16:01 UTC
[Rubyinstaller-devel] OT: FYI - Will be partially away the next days
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).
Luis Lavena
2009-Aug-21 16:13 UTC
[Rubyinstaller-devel] OT: FYI - Will be partially away the next days
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
Alexey Borzenkov
2009-Aug-21 16:55 UTC
[Rubyinstaller-devel] OT: FYI - Will be partially away the next days
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
Luis Lavena
2009-Aug-24 21:06 UTC
[Rubyinstaller-devel] OT: FYI - Will be partially away the next days
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
Alexey Borzenkov
2009-Aug-25 19:25 UTC
[Rubyinstaller-devel] OT: FYI - Will be partially away the next days
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.