Re: [csw-maintainers] #ifdef's for solaris versions
Hi Riccardo, Am 08.09.2013 um 21:32 schrieb Riccardo Mottola : > On 09/07/13 17:57, Maciej (Matchek) BliziÅski wrote: >> 2013/9/7 Riccardo Mottola >>> Are there reliable #ifdef's for identifying solaris? and then, in case, its >>> versions? I need certain workaround for solaris and, furthermore some are >>> needed only for solaris 8/9, but no longer in 10+. (I'm struggling with the >>> missing stdint.h and the incomplete inttypes.h) >> >> Why not have a ./configure test for the exact feature or bug you're >> interested in detecting, and an own #define? > > First, not everything is easy to check, also these tests need to work on > non-solaris platforms. Perhaps you do have some ready tests? > The first problem is checking for stdint.h: that's easy, the alternative is > inttypes. But then checking for various macros, some of those are defined > "blank" on solaris 8/9, not just undefined. (MIN/MAX limits, PRTuPTR and that > kind of stuff). I suggest seeking inspiration from other portable projects like vlc, rdesktop or mpg123. Apart from that I guess 'host' in autoconf is what you are looking for: http://www.sourceware.org/autobook/autobook/autobook_261.html#SEC261 Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 smime.p7s Description: S/MIME cryptographic signature ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] External discussions about our project
Hi Maciej, Am 08.09.2013 um 23:19 schrieb Maciej (Matchek) Bliziński : > I just found this thread from comp.os.solaris, in April this year: > > https://groups.google.com/d/msg/comp.unix.solaris/FRucD_DUXrQ/gEHRwubhZzQJ > > My first impression is that they didn't like our getting started > instructions. What should we do? Consolidate? (that is: delete as many > pages as possible, move content to one place, put links and/or > redirects everywhere else) Probable increase the font size and make it look like web 2.0 similar to http://mosh.mit.edu Apart from that David had problems gettings started three years ago: https://groups.google.com/forum/#!topic/comp.unix.solaris/AIj_dYgPB0M Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 smime.p7s Description: S/MIME cryptographic signature ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Anniversary Shirts for Berlin
Thanks, Size: XL Carsten Am 09.09.13 schrieb Dagobert Michelsen : > Hi folks, > > there will be t-shirts again for the Summercamp in Berlin! If you want one > you need to tell me the size until tomorrow morning latest, earlier is better. > > > Best regards > > -- Dago > > -- > "You don't become great by trying to be great, you become great by wanting to > do something, > and then doing it so hard that you become great in the process." - xkcd #896 > > > ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
[csw-maintainers] Anniversary Shirts for Berlin
Hi folks, there will be t-shirts again for the Summercamp in Berlin! If you want one you need to tell me the size until tomorrow morning latest, earlier is better. Best regards -- Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 smime.p7s Description: S/MIME cryptographic signature ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] #ifdef's for solaris versions
2013/9/8 Juraj Lutter : > To make long story short: > > On Solaris, gcc and sunstudio(?) #defines "sun" and gcc defines also > "__sun" so > > #if defined(sun) || defined(__sun) > ... > #endif > > will compile block on Solaris plarform. It has been described in our porting FAQ: http://wiki.opencsw.org/porting-faq#toc22 But this isn't what Riccardo asked. He wanted to detect whether we're on e.g. Solaris 9 or Solaris 10. Maciej ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] #ifdef's for solaris versions
On 09/08/13 23:51, Maciej (Matchek) Bliziński wrote: > 2013/9/8 Riccardo Mottola : >> Hi, >> >> >> On 09/07/13 17:57, Maciej (Matchek) BliziÅ„ski wrote: >>> >>> 2013/9/7 Riccardo Mottola Are there reliable #ifdef's for identifying solaris? and then, in case, its versions? I need certain workaround for solaris and, furthermore some are needed only for solaris 8/9, but no longer in 10+. (I'm struggling with the missing stdint.h and the incomplete inttypes.h) >>> >>> Why not have a ./configure test for the exact feature or bug you're >>> interested in detecting, and an own #define? >> >> First, not everything is easy to check, also these tests need to work on >> non-solaris platforms. Perhaps you do have some ready tests? >> The first problem is checking for stdint.h: that's easy, the alternative is >> inttypes. But then checking for various macros, some of those are defined >> "blank" on solaris 8/9, not just undefined. (MIN/MAX limits, PRTuPTR and >> that kind of stuff). > > If you could describe here an example of a test that doesn't look > easy, maybe someone would chime in with a hint. Is your code available > to be viewed? If not, can you post a snippet that breaks? > >> Furthermore, configure is easy for a program, but more difficult to use for >> a library, a Framework where you install headers, because you don't install >> config.h, or at least so I understand it. > > It's possible. You do install config.h, giving it either a unique name > such as project-config.h or putting it into a project-specific > directory. > > http://www.openismus.com/documents/linux/building_libraries/building_libraries#installingheaders > http://stackoverflow.com/questions/1810216/autoconf-where-does-config-h-go > which links to: > http://www.gnu.org/software/autoconf-archive/ax_prefix_config_h.html To make long story short: On Solaris, gcc and sunstudio(?) #defines "sun" and gcc defines also "__sun" so #if defined(sun) || defined(__sun) ... #endif will compile block on Solaris plarform. More information: http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system -- Juraj Lutter ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] #ifdef's for solaris versions
2013/9/8 Riccardo Mottola : > Hi, > > > On 09/07/13 17:57, Maciej (Matchek) Bliziński wrote: >> >> 2013/9/7 Riccardo Mottola >>> >>> Are there reliable #ifdef's for identifying solaris? and then, in case, >>> its versions? I need certain workaround for solaris and, furthermore some >>> are needed only for solaris 8/9, but no longer in 10+. (I'm struggling with >>> the missing stdint.h and the incomplete inttypes.h) >> >> Why not have a ./configure test for the exact feature or bug you're >> interested in detecting, and an own #define? > > First, not everything is easy to check, also these tests need to work on > non-solaris platforms. Perhaps you do have some ready tests? > The first problem is checking for stdint.h: that's easy, the alternative is > inttypes. But then checking for various macros, some of those are defined > "blank" on solaris 8/9, not just undefined. (MIN/MAX limits, PRTuPTR and > that kind of stuff). If you could describe here an example of a test that doesn't look easy, maybe someone would chime in with a hint. Is your code available to be viewed? If not, can you post a snippet that breaks? > Furthermore, configure is easy for a program, but more difficult to use for > a library, a Framework where you install headers, because you don't install > config.h, or at least so I understand it. It's possible. You do install config.h, giving it either a unique name such as project-config.h or putting it into a project-specific directory. http://www.openismus.com/documents/linux/building_libraries/building_libraries#installingheaders http://stackoverflow.com/questions/1810216/autoconf-where-does-config-h-go which links to: http://www.gnu.org/software/autoconf-archive/ax_prefix_config_h.html > So if you have some solaris ifdef's I would still a appreciate :) There must > be! Perhaps a mix of the two tings will eventually help me better. No, this is a wrong way of doing this. All you need is to learn how to write tests and use the results. Maciej ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
[csw-maintainers] External discussions about our project
I just found this thread from comp.os.solaris, in April this year: https://groups.google.com/d/msg/comp.unix.solaris/FRucD_DUXrQ/gEHRwubhZzQJ My first impression is that they didn't like our getting started instructions. What should we do? Consolidate? (that is: delete as many pages as possible, move content to one place, put links and/or redirects everywhere else) Maciej ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] #ifdef's for solaris versions
Hi, On 09/07/13 17:57, Maciej (Matchek) BliziÅski wrote: 2013/9/7 Riccardo Mottola Are there reliable #ifdef's for identifying solaris? and then, in case, its versions? I need certain workaround for solaris and, furthermore some are needed only for solaris 8/9, but no longer in 10+. (I'm struggling with the missing stdint.h and the incomplete inttypes.h) Why not have a ./configure test for the exact feature or bug you're interested in detecting, and an own #define? First, not everything is easy to check, also these tests need to work on non-solaris platforms. Perhaps you do have some ready tests? The first problem is checking for stdint.h: that's easy, the alternative is inttypes. But then checking for various macros, some of those are defined "blank" on solaris 8/9, not just undefined. (MIN/MAX limits, PRTuPTR and that kind of stuff). Furthermore, configure is easy for a program, but more difficult to use for a library, a Framework where you install headers, because you don't install config.h, or at least so I understand it. So if you have some solaris ifdef's I would still a appreciate :) There must be! Perhaps a mix of the two tings will eventually help me better. Riccardo ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] upload error
Laurent Blume writes: > On 2013-09-08 2:29 PM, rupert THURNER wrote: >> hi, i created the current mercurial packages today by: >> rupert @ unstable10x : ~/opencsw/mercurial/trunk >>mgar up >>mgar spotless remerge replatforms >> >> and the upload fails with: >> >> rupert @ login : ~ >> $ csw-upload-pkg >> pkgs/08.Sep.2013/mercurial-2.7.1\,REV\=2013.09.08-SunOS5.10-* >> Processing 2 file(s). Please wait. >> Traceback (most recent call last): >> File "/opt/csw/bin/csw-upload-pkg", line 509, in >> uploader.Upload() >> File "/opt/csw/bin/csw-upload-pkg", line 168, in Upload >> filename, self.catrel, arch, osrel, md5_sum) >> File "/opt/csw/bin/csw-upload-pkg", line 243, in _MatchSrv4ToCatalogs >> arch, osrel, srv4_in_catalog["osrel"], catalogname) >> KeyError: 'osrel' >> >> what did i overlook? > > Have you done an "mgar up --all" to be sure you picked all the little > bits? I had a similar issue yesterday, the full update fixed it for me > (Maciej had fixed the issue I was hitting). cd ~/opencsw/.buildsys/v2 && svn up . is the necessary and sufficient -- Peter ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] upload error
On 2013-09-08 2:29 PM, rupert THURNER wrote: > hi, i created the current mercurial packages today by: > rupert @ unstable10x : ~/opencsw/mercurial/trunk >mgar up >mgar spotless remerge replatforms > > and the upload fails with: > > rupert @ login : ~ > $ csw-upload-pkg pkgs/08.Sep.2013/mercurial-2.7.1\,REV\=2013.09.08-SunOS5.10-* > Processing 2 file(s). Please wait. > Traceback (most recent call last): > File "/opt/csw/bin/csw-upload-pkg", line 509, in > uploader.Upload() > File "/opt/csw/bin/csw-upload-pkg", line 168, in Upload > filename, self.catrel, arch, osrel, md5_sum) > File "/opt/csw/bin/csw-upload-pkg", line 243, in _MatchSrv4ToCatalogs > arch, osrel, srv4_in_catalog["osrel"], catalogname) > KeyError: 'osrel' > > what did i overlook? Have you done an "mgar up --all" to be sure you picked all the little bits? I had a similar issue yesterday, the full update fixed it for me (Maciej had fixed the issue I was hitting). Laurent ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
[csw-maintainers] upload error
hi, i created the current mercurial packages today by: rupert @ unstable10x : ~/opencsw/mercurial/trunk mgar up mgar spotless remerge replatforms and the upload fails with: rupert @ login : ~ $ csw-upload-pkg pkgs/08.Sep.2013/mercurial-2.7.1\,REV\=2013.09.08-SunOS5.10-* Processing 2 file(s). Please wait. Traceback (most recent call last): File "/opt/csw/bin/csw-upload-pkg", line 509, in uploader.Upload() File "/opt/csw/bin/csw-upload-pkg", line 168, in Upload filename, self.catrel, arch, osrel, md5_sum) File "/opt/csw/bin/csw-upload-pkg", line 243, in _MatchSrv4ToCatalogs arch, osrel, srv4_in_catalog["osrel"], catalogname) KeyError: 'osrel' what did i overlook? rupert ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Integrating unstable→testing — handover
2013/9/8 Peter FELECAN : > Adding this information helps. The date of the deletion also to keep the > "certain time". Of course, the flag can be negated if the package is > re-instantiated. Yes. The problem is that this will require a database schema change and code changes in multiple places. > BTW, what about increasing the size of created_by attribute to contain a > group of maintainers? This field isn't the maintainer, it's the user who initiated the call to insert a package into a catalog. It also currently doesn't work because of the proxy issue we discussed earlier. http://lists.opencsw.org/pipermail/maintainers/2013-May/018107.html Maciej ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Integrating unstable→testing ― handover
"Maciej (Matchek) Bliziński" writes: > 2013/9/7 Laurent Blume >> >> On 2013-09-07 8:29 PM, Maciej (Matchek) Bliziński wrote: >> > So far, I've tried to make the package promotion as simple as >> > possible. Ideally, it was an equivalent of taking a snapshot of >> > unstable and making it the testing catalog. >> >> Since that's basically what I'm doing in production, I'm all for it. > > In practice it wasn't that simple, there usually were packages I wanted to > skip. > > Another thing is deletions: we need to propagate them as well, but the > database currently doesn't hold the information about when a package > was removed from a catalog. This might be an inconvenient feature to > implement. > > We currently have a table which connects a svr4 file, catalog release, > OS release and architecture. > > mysql> describe srv4_file_in_catalog; > +-+-+--+-+-++ > | Field | Type| Null | Key | Default | Extra | > +-+-+--+-+-++ > | id | int(11) | NO | PRI | NULL| auto_increment | > | arch_id | int(11) | NO | MUL | NULL|| > | osrel_id| int(11) | NO | MUL | NULL|| > | catrel_id | int(11) | NO | MUL | NULL|| > | srv4file_id | int(11) | NO | MUL | NULL|| > | created_on | datetime| NO | | NULL|| > | created_by | varchar(50) | NO | | NULL|| > +-+-+--+-+-++ > 7 rows in set (0.37 sec) > > A row in this table means that such-and-such package is in a specific > catalog. If we want to keep the information about deletions, we'll > have to keep the row, but the row would need to contain a flag > indicating that the package has been removed at certain time. Adding this information helps. The date of the deletion also to keep the "certain time". Of course, the flag can be negated if the package is re-instantiated. BTW, what about increasing the size of created_by attribute to contain a group of maintainers? -- Peter ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] Integrating unstable→testing ― handover
"Maciej (Matchek) Bliziński" writes: > 2013/9/7 Peter FELECAN >> IMHO, we need to find somebody to implement the automatic transition >> from unstable to testing. Remember, we decided that the transition is >> made when there is no blocking issue reported in our BTS after 2 weeks >> from release time. > > Right. We might start moving in this direction. The database already > stores the required information: when was each package inserted into > which catalog. There is no REST API for it though. I'll see if I can > add it. > > I'm also thinking that when we transition to the 2 week automatic > package promotion, we'll come across a new failure scenario. For > example, 2 co-dependent packages are uploaded, let's call them CSWfoo > and CSWbar. A bug is discovered in CSWbar. A fixed version of CSWbar > is uploaded a week later. But the timer on CSWfoo hasn't been reset, > so CSWfoo gets promoted without the accompanying CSWbar. This causes > CSWbar to be broken in the testing catalog. Of course, the promotion of a package can be done only if all its dependencies can be or are already promoted. This additional complexity is the probable cause of it not being yet implemented. > So far, I've tried to make the package promotion as simple as > possible. Ideally, it was an equivalent of taking a snapshot of > unstable and making it the testing catalog. Oversimplification is its name. -- Peter ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
