Ros-dev February 2012

ros-dev@reactos.org

38 participants
51 discussions

Good bye RBuild
by Pierre Schweitzer 25 Aug '12

25 Aug '12

Hi, after having finished its 11405th build, the last official RBuild builder has gone offline, forever. The Linux CMake builder has now turned as being the official builder. Thanks RBuild, you served us well :-). Also, the other RBuild builder, the release builder has also gone offline forever. Its hardware was not able to properly handle a ReactOS build, and was hardly upgradable. Daily release builds should replace it any time soon. With my best regards, -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

4 4

Re: [ros-dev] [ros-builds] Linux_AMD64_1 KVM-CMake-Test: build failed
by Pierre Schweitzer 03 Mar '12

03 Mar '12

This is due to an issue within both ReactOS and sysreg. ReactOS appears not to boot any longer with r55879 on KVM, and crashing during ntoskrnl init on CD. Sysreg is also not catching the crash, nor hitting the timeout and so is not killing the VM. And then, buildbot is unable to start any new test due to the frozen VM. I have killed the frozen VM and restarted HEAD (ie, r55886 testing). If the fix has been really committed with r55880, it should work properly. Will investigate the issue ASAP, to ensure it doesn't happen any more. Le lundi 27 février 2012 à 17:40 +0000, buildbot(a)reactos.org a écrit : > The Buildbot has detected a failed build on builder Linux_AMD64_1 KVM-CMake-Test while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Linux_AMD64_1%20KVM-CMake-Test/builds/76 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1 > > Build Reason: Triggerable(Linux_AMD64_1 KVM-CMake-Test Trigger) > Build Source Stamp: 55886 > Blamelist: ion > > BUILD FAILED: failed test > > sincerely, > -The Buildbot > > -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 1

Cmake result differences
by Bernd Blaauw 01 Mar '12

01 Mar '12

I was wondering why the Cmake results are different between the Windows/ReactOS and Unix/Linux platforms. The compressed trunk CD images available for download differ by about 6MB. Expecting identical output (checksums, file sizes) on different platforms even with the same compiler isn't realistic ofcourse but above mentioned 6MB is a bit much. Creating dbgwin-builds makes sense, but if the Unix builder builds faster and smaller builds, and makes them earlier available for download, what's the point in making the Windows build available publicly? Would it make more sense to offer MSVC builds if license-technical allowed? Or automated builds of CLT-type (combined installCD + liveCD) ? Bernd

5 8

Rasberry Pi
by Ged Murphy 29 Feb '12

29 Feb '12

It looks like the model B boards are now in manufacture. http://www.raspberrypi.org/archives/509 There are only 10k being made being made in this batch and demand is really high, so I doubt they'll last longer than a few minutes. With only 256MB RAM available, I doubt Windows 8 will ever run on it although Windows Embedded Compact 7 might. I know the reactos arm port is still a way off, but this could be a golden opportunity for reactos. At $25 per computer, they're gonna sell hundreds of thousands of these things and most buyers will be enthusiasts/developers. Ged.

18 38

KVM regtest CDs available
by Pierre Schweitzer 29 Feb '12

29 Feb '12

Hi, to address an increasing ReactOS developers demand, you'll be able to find regtest CDs used by KVM testbot at the URL: http://iso.reactos.org/regtestcd/ I think I'll probably put the KVM testbot machine specifications on the wiki to help as well. Regards, -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 0

Re: [ros-dev] [ros-builds] CMake_x86_GCCLin Debug: build failed
by Pierre Schweitzer 28 Feb '12

28 Feb '12

This is due to the new way test CDs are handled on the builder. I'm on it to get it back to working state. Le mardi 28 février 2012 à 22:22 +0000, buildbot(a)reactos.org a écrit : > The Buildbot has detected a failed build on builder CMake_x86_GCCLin Debug while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/CMake_x86_GCCLin%20Debug/builds/96 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1 > > Build Reason: scheduler > Build Source Stamp: 55909 > Blamelist: janderwald > > BUILD FAILED: failed compile_5 > > sincerely, > -The Buildbot > > -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 0

mikeos
by mikey sibert 27 Feb '12

27 Feb '12

can you send me a copy of mikeos 4.3 because it is blocked for me and i cant download it i am going to base a 16 bit os off of it

2 1

February 2012 Meeting Minutes
by Amine Khaldi 27 Feb '12

27 Feb '12

February 2012 Meeting Minutes 2012-02-23 19:45 UTC Fezile, #meeting Proceedings =========== * Meeting started at 19:45 UTC by Aleksey Bragin. * Point 1: Release status: 0.3.15 --------------------------------- * Aleksey Bragin proposed that we prepare trunk and release 0.3.15, as it is now, before anything major happens. Several members then wondered about the status of USB and the "mshtml bug". Jerome Gardou explained a bit about how the mshtml bug is far from completely being fixed, because if you look at testbot's results, there are still some problems with ASSERTs hit and some bad pagefaults happening when paging out. * A lengthy discussion occurred, about how ready trunk is, whether it's in a better state than 0.3.14, the state of the theme to be bundled with ros, the plan for CLT, whether we should go 0.4<something> or 0.3.15... This was settled through a voting: "Do you agree to release 0.3.15 with current trunk features, before CLT?". * The total number of votes was 21, with 11 votes as Yes, 5 as No, and 5 abstentions. As a result, we will be having a 0.3.15 release with CLT being the deadline. * Point 2: New website status and migration plans ------------------------------------------------- * Amine Khaldi gave a quick summary on the state of the website revamp: - Quite some progress has been made in the theming department, and it's visible from the playground. It's starting to look a lot like the current one, which means it's almost done (only some issues are left). - Maciej Bialas has been investigating how to import users from the RosCMS. We will most likely need to compromise: members will have to reenter passwords when we migrate, but we'll see. - Amine Khaldi then mentioned that we need help from web devs familiar with Drupal. Alexander Rechitskiy mentioned that he has a guy that wants to be part of the web team, and he passes his info to Amine to establish the contact. - He also mentioned that Maciej is very busy, so the progress will slow down, and that the current short term plan is to continue the theming work, provide a way to import users, import the rest of data from wiki/bugzilla...etc and finally add the phpbb bridge. * He then summarized the summary by saying: We needs skillful drupal guys, we're almost there, and that's it. * Point 3: CMake migration and finally abandoning RBuild -------------------------------------------------------- * Amine Khaldi suggested that it's time to ditch rbuild, as he suspects most of our members have migrated already. Agreement on that, from ours members, was unprecedented as *everyone* were on favor of this :) * We agreed on doing the necessary commits/infrastructure changes ASAP, ie "tonight" (relative to the meeting of course), but that didn't happen just yet so it's just a matter of time. Amine Khaldi wants to do the honors (the commit that will remove rbuild and its related files). * Amine Khaldi also mentioned that he's preparing a nice little surprise for major build performance boost, on many levels, so stay tuned guys ;) * Jerome Gardou explained that he'll be handling the PCH support to get it to a much better state than it is right now. * Point 4: Added per Amine Khaldi's request: GSoC preparations -------------------------------------------------------------- * Amine Khaldi explained that he created a Google Doc and invited the interested members. He asked the members to collaborate and shape up an excellent ideas list, projects that fit in GSoC at both the time and complexity levels. * Colin suggested building up on the last year in terms of informative content (wiki pages from last year), covering questions about how we deal with students, our application form... etc. * Meeting closed at 21:45 UTC by Aleksey Bragin. * Minutes written by Amine Khaldi.

13 19

Re: [ros-dev] [ros-diffs] [pschweitzer] 55861: [USER32] Correct user32 japanese translation (and fix build as well)
by Amine Khaldi 25 Feb '12

25 Feb '12

> [USER32] > Correct user32 japanese translation (and fix build as well) For the record, this doesn't fix build because: 1) It was not broken (hint: r55860). 2) The module that broke build back then was shell32, not user32. Regards, Amine.

2 1

Re: [ros-dev] [ros-diffs] [dgorbachev] 55835: [FREELDR][NTOSKRNL] Update linker scripts.
by Timo Kreuzer 24 Feb '12

24 Feb '12

Hi, Can we rename linker scripts to .lds or something? It's annoying to see the shortcut overlay instead of tsvn overlay on the .lnk files. Regards, Timo Am 23.02.2012 19:59, schrieb dgorbachev(a)svn.reactos.org: > Author: dgorbachev > Date: Thu Feb 23 18:59:24 2012 > New Revision: 55835 > > URL: http://svn.reactos.org/svn/reactos?rev=55835&view=rev > Log: > [FREELDR][NTOSKRNL] > Update linker scripts. > > Modified: > trunk/reactos/boot/freeldr/freeldr/freeldr_i386.lnk > trunk/reactos/ntoskrnl/ntoskrnl_i386.lnk > > Modified: trunk/reactos/boot/freeldr/freeldr/freeldr_i386.lnk > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/freel… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/freeldr_i386.lnk [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/freeldr_i386.lnk [iso-8859-1] Thu Feb 23 18:59:24 2012 > @@ -23,6 +23,15 @@ > __bss_end__ = . ; > } > > + .stab BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.stab) > + } > + .stabstr BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.stabstr) > + } > + > /* DWARF debug sections. > Symbols in the DWARF debugging sections are relative to the beginning > of the section. Unlike other targets that fake this by putting the > @@ -43,7 +52,7 @@ > /* DWARF 2. */ > .debug_info BLOCK(__section_alignment__) (NOLOAD) : > { > - *(.debug_info) *(.gnu.linkonce.wi.*) > + *(.debug_info .gnu.linkonce.wi.*) > } > .debug_abbrev BLOCK(__section_alignment__) (NOLOAD) : > { > @@ -98,7 +107,7 @@ > /* DWARF 4. */ > .debug_types BLOCK(__section_alignment__) (NOLOAD) : > { > - *(.debug_types) *(.gnu.linkonce.wt.*) > + *(.debug_types .gnu.linkonce.wt.*) > } > > /DISCARD/ : > > Modified: trunk/reactos/ntoskrnl/ntoskrnl_i386.lnk > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ntoskrnl_i386.lnk… > ============================================================================== > --- trunk/reactos/ntoskrnl/ntoskrnl_i386.lnk [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ntoskrnl_i386.lnk [iso-8859-1] Thu Feb 23 18:59:24 2012 > @@ -1,105 +1,150 @@ > -OUTPUT_FORMAT(pei-i386) > -ENTRY(_mainCRTStartup) > SECTIONS > { > - .text __image_base__ + __section_alignment__ : > + .text __image_base__ + __section_alignment__ : > { > - __text_start__ = .; > - *(.init) > *(.text) > - *(SORT(.text$*)) > - *(.glue_7t) > - *(.glue_7) > - ___CTOR_LIST__ = .; __CTOR_LIST__ = . ; > - LONG (-1); *(.ctors); *(.ctor); LONG (0); > - ___DTOR_LIST__ = .; __DTOR_LIST__ = . ; > - LONG (-1); *(.dtors); *(.dtor); LONG (0); > - *(.fini) > - /* ??? Why is .gcc_exc here? */ > - *(.gcc_exc) > - __text_end__ = .; > - *(.gcc_except_table) > + *(SORT(.text*)) > } > - /* The Cygwin32 library uses a section to avoid copying certain data > - on fork. This used to be named ".data". The linker used > - to include this between __data_start__ and __data_end__, but that > - breaks building the cygwin32 dll. Instead, we name the section > - ".data_cygwin_nocopy" and explictly include it after __data_end__. */ > - .data BLOCK(__section_alignment__) : > + > + .data BLOCK(__section_alignment__) : > { > - __data_start__ = . ; > *(.data) > - *(.data2) > - *(SORT(.data$*)) > - __data_end__ = . ; > - *(.data_cygwin_nocopy) > + *(SORT(.data*)) > } > + > .rdata BLOCK(__section_alignment__) : > { > *(.rdata) > - *(SORT(.rdata$*)) > + *(SORT(.rdata*)) > *(.eh_frame) > } > + > .edata BLOCK(__section_alignment__) : > { > *(.edata) > } > + > /DISCARD/ : > { > - *(.debug$S) > - *(.debug$T) > - *(.debug$F) > *(.drectve) > + *(.gnu.lto_*) > } > > .idata BLOCK(__section_alignment__) : > { > /* This cannot currently be handled with grouped sections. > - See pe.em:sort_sections. */ > + See pe.em:sort_sections. */ > SORT(*)(.idata$2) > SORT(*)(.idata$3) > /* These zeroes mark the end of the import list. */ > LONG (0); LONG (0); LONG (0); LONG (0); LONG (0); > - SORT(*)(.idata$4) > + SORT(*)(.idata$4) > SORT(*)(.idata$5) > SORT(*)(.idata$6) > SORT(*)(.idata$7) > } > - .CRT BLOCK(__section_alignment__) : > - { > - *(SORT(.CRT$*)) > - } > + > .rsrc BLOCK(__section_alignment__) : > - { > + { > *(.rsrc) > *(SORT(.rsrc$*)) > } > + > .bss BLOCK(__section_alignment__) : > { > - __bss_start__ = . ; > *(.bss) > *(COMMON) > - __bss_end__ = . ; > } > + > .reloc BLOCK(__section_alignment__) : > - { > + { > *(.reloc) > - /* These zeroes mark the end of the reloc section. */ > - LONG (0); LONG (0); LONG (0); LONG (0); LONG (0); > } > + > .stab BLOCK(__section_alignment__) (NOLOAD) : > { > - [ .stab ] > + *(.stab) > } > .stabstr BLOCK(__section_alignment__) (NOLOAD) : > { > - [ .stabstr ] > + *(.stabstr) > } > - INIT BLOCK(__section_alignment__) : > + > + /* DWARF debug sections. > + Symbols in the DWARF debugging sections are relative to the beginning > + of the section. Unlike other targets that fake this by putting the > + section VMA at 0, the PE format will not allow it. */ > + /* DWARF 1.1 and DWARF 2. */ > + .debug_aranges BLOCK(__section_alignment__) (NOLOAD) : > { > - __init_start__ = . ; > - *(INIT) > - __init_end__ = . ; > + *(.debug_aranges) > + } > + .debug_pubnames BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_pubnames) > + } > + .debug_pubtypes BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_pubtypes) > + } > + /* DWARF 2. */ > + .debug_info BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_info .gnu.linkonce.wi.*) > + } > + .debug_abbrev BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_abbrev) > + } > + .debug_line BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_line) > + } > + .debug_frame BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_frame*) > + } > + .debug_str BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_str) > + } > + .debug_loc BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_loc) > + } > + .debug_macinfo BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_macinfo) > + } > + /* SGI/MIPS DWARF 2 extensions. */ > + .debug_weaknames BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_weaknames) > + } > + .debug_funcnames BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_funcnames) > + } > + .debug_typenames BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_typenames) > + } > + .debug_varnames BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_varnames) > + } > + .debug_macro BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_macro) > + } > + /* DWARF 3. */ > + .debug_ranges BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_ranges) > + } > + /* DWARF 4. */ > + .debug_types BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_types .gnu.linkonce.wt.*) > } > } > - > > >

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev February 2012