Re: [csw-maintainers] Integrating unstable→testing ― handover
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. 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
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. Laurent ___ 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/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. 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. 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] New ImageMagick
On 2013-09-07 8:17 PM, Joerg Schilling wrote: > Laurent Blume wrote: > >> On 2013-09-07 3:48 PM, Maciej (Matchek) Blizi??ski wrote: >>> 2013/7/17 Laurent Blume Even with using -xO5, Studio is still about 10% slower than GCC4.8. >>> >>> Interesting. I'm curious what would be the GCC vs Studio benchmarks on >>> SPARC. >> >> Yes, me too. I still have a plan to run my bench on the M3000 at work, >> There's one box that's just for that. > > AFAIK, -fast is more than -xO5 > > did you test that? I tried -native (included in -fast). Studio crashed. GCC won by being about ∞× faster. Laurent ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] New ImageMagick
Laurent Blume wrote: > On 2013-09-07 3:48 PM, Maciej (Matchek) Blizi??ski wrote: > > 2013/7/17 Laurent Blume > >> Even with using -xO5, Studio is still about 10% slower than GCC4.8. > > > > Interesting. I'm curious what would be the GCC vs Studio benchmarks on > > SPARC. > > Yes, me too. I still have a plan to run my bench on the M3000 at work, > There's one box that's just for that. AFAIK, -fast is more than -xO5 did you test that? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
Re: [csw-maintainers] New ImageMagick
On 2013-09-07 3:48 PM, Maciej (Matchek) Bliziński wrote: > 2013/7/17 Laurent Blume >> Even with using -xO5, Studio is still about 10% slower than GCC4.8. > > Interesting. I'm curious what would be the GCC vs Studio benchmarks on SPARC. Yes, me too. I still have a plan to run my bench on the M3000 at work, There's one box that's just for that. Laurent ___ 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 2013-09-07 5:57 PM, 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? Actually, so far, it's the *only* way. Unlike for Linux distros,which are very stable, Solaris features do vary a lot during the lifetime of a given release. So, the major number is meaningless (you could even have the case where a patched version N has a feature than an unpatched N+1 does not). Update versions don't mean much, since you can get a feature via a patch without changing the update, Patch numbers are unreliable: you would need to know what patch number introduced a feature, but it'll probably be rolled into another patch later. And we're getting far of a simple #ifdef check here. This is all less true in Solaris 11, which has tightened the integration, and forces you the hard way to have an all or nothing upgrade. It still remains to be seen how it will evolve. So, like Maciej said - configure. Laurent ___ 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: > I've pasted in the integration documentation into our wiki: > > http://wiki.opencsw.org/automated-release-process#toc4 > > The issue is still open, we're looking for someone to handle > catalog integrations. 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. -- 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
I've pasted in the integration documentation into our wiki: http://wiki.opencsw.org/automated-release-process#toc4 The issue is still open, we're looking for someone to handle catalog integrations. 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
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? ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
[csw-maintainers] #ifdef's for solaris versions
Hi, while a bit off-topic, since I am not speaking of software currently packaged, I bet you experienced this in the past while porting. I also hope GNUstep software will get into the packages sooner or later! 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) Ideally something like this: #if solaris #if Solaris=8 xxx #else #endif On Mac, extremely convenient macros are provided where I can check for each evrsion, including doing stuff like "<10.4."... but I did not find equivalent. Since these these patches would go directly in upstream, I need them no to impact anything else! Thank you. I will later report my progress. 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] New ImageMagick
2013/7/17 Laurent Blume > Even with using -xO5, Studio is still about 10% slower than GCC4.8. Interesting. I'm curious what would be the GCC vs Studio benchmarks on SPARC. Maciej ___ maintainers mailing list maintainers@lists.opencsw.org https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
