Re: Neutral / shared security list ...
Am 27.10.2011 02:55, schrieb Peter Junge: strongI totally agree with Florian./strong Please stop this cold war fought with pointless rhetoric. +1 On 10/25/2011 11:56 PM, Florian Effenberger wrote: Hello, it is really amazing how much hot air can be produced for such a topic. Folks, it's rather easy. After the recent discussions and the history of this topic, it becomes obvious, that neutral grounds are important. Neutral grounds mean: - no domain name related to Apache, OOo, TDF or LibO - no hosting at one of these entities - members of the list from both parties (and of course other third parties that make sense) - admins of the list from both parties I'd also avoid any of the German associations, either directly or via donations, since stakeholders at both projects are in their respective boards, which might raise concerns towards neutrality. What's so complicated to understand here? We can bury ourselves with senselessly quoting bullshit from dictionaries, wikipedia or a philospher of our choice, or finally start working on things. A concrete proposal: - We can use either FreeDesktop.org, - or in case this is seen as non-neutral as it hosts also a few TDF lists (not all), go for SourceForge. - I am also happy to ask a friend of mine who is in the business of mail server consultancy, to host that list under a neutral domain name. He hosts various lists for free projects. In case that's not neutral enough as he's a friend, I know none of the admins at SourceForge. So, is there any *compelling* reason not to try out one of these three options? Florian
Re: odt2braille on the Mac
Hi Bert, i assume it is again a threading issue on MacOS and the used Java API requires the main thread as well. I don't have a solution yet for you and i am not aware of any existing solution but we have to solve this issue anyway. But at the moment we have many other thinks to do with our ongoing IP clearance. But your extensions is quite interesting and of course very useful for probably many users. We can also think about a further UNO API to ask for the system default printer because the code should be available somewhere. Please keep us informed or ping us again in the future when we have more time to focus on this problem. Juergen On 10/25/11 5:17 PM, Bert Frees wrote: Hi Alexandro, Thanks for your suggestion. Something I didn't mention yet is that I need an interface that can send raw data (a byte stream) to a printer driver. The problem with braille printers is that they're very different from normal ink printers. A braille printer is more like an old dotmatrix or impact printer, and is controlled with special escape sequences and codes that define where a braille dot has to be placed on the paper. Is it possible to send raw data to a printer using this API? Best, Bert On 25/10/2011 16:41, Alexandro Colorado wrote: hi, i think it might be better to usee the uno api for the printing services. http://wiki.services.openoffice.org/wiki/API/Samples/Java/Office/DocumentHandling#DocumentPrinter On 10/25/11, Bert Freesbertfr...@gmail.com wrote: Hi all, My name is Bert Frees. I'm the developer of odt2braille, the Braille plugin for OOo: http://odt2braille.sourceforge.net/index.html. Some time ago I raised an issue on the old developer list (see e-mail below), but I got no reaction. I'm bringing it up again on this list in the hope somebody here can help me out. I'm not a Mac expert at all, but I get a lot of requests for Mac support. A lot of people would be very happy if this got solved. Thanks in advance, Bert Frees -- Bert Frees Katholieke Universiteit Leuven Dept. Elektrotechniek - ESAT - SCD Onderzoeksgroep Documentarchitecturen Kasteelpark Arenberg 10 bus 2442 B-3001 Heverlee-Leuven België Original Message Subject: odt2braille on the Mac Date: Mon, 16 May 2011 11:55:37 +0200 From: Bert Freesbertfr...@gmail.com To: d...@openoffice.org Hello, I'm new to this mailing list. My name is Bert Frees. I am the developer of odt2braille, the OpenOffice.org plugin for printing and exporting Braille. The website is http://odt2braille.sourceforge.net/index.html. I'm trying to make this plugin available on the Mac, but I've been puzzling on a bug for some time now and I'm really stuck. I hope there is somebody on this list who is familiar with OOo on the Mac, and who knows what might be the problem. I'm using javax.print.PrintServiceLookup http://download.oracle.com/javase/1.4.2/docs/api/javax/print/PrintServiceLookup.html to look up the default printer device. It works fine on Windows, but on Mac OS it causes OOo to crash. Also, I'm sure the problem is OOo-related because the code runs fine when it is not embedded in an OOo extension. This is the code: javax.print.PrintService[] printers = javax.print.PrintServiceLookup.lookupDefaultPrintService(); Thanks, Bert
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
On 9/22/11 1:19 PM, Jürgen Schmidt wrote: ok, we have several arguments for and against but no decision how we want to move forward. Let us take again a look on it 1. we have a working mechanism to get the externals from somewhere, check md5 sum, unpack, patch, build 1.1 somewhere is configurable during the configure step, initially the externals are downloaded from http://hg.services.openoffice.org/binaries 2. having the externals in the repository (SVN) won't be a big issue because in case of a checkout always the tip version is downloaded 2.1 the SCM can be used to track the used version of the externals for a specific OO version - simply checkout the version tag and everything is in place ... 3. in a DSCM it would be a real problem over time because of the increasing space of all versions 4. we need a replacement http://hg.services.openoffice.org/binaries asap (who knows how long the server will be available) 5. many developers probably work with a local clone of the repository using for example git svn or something else - disadvantage of the increasing space but probably acceptable if a clean local trunk will be kept and updated Proposed way to move forward 1. put the externals under .../trunk/ext_sources .../trunk/ext_sources .../trunk/main .../trunk/extras 2. adapt configure to use this as default, disable the download (maybe reactivate it later if we move to a DSCM) 3. keep the process with checking the md5 sum as it is (for potential later use) Any opinions or suggestions? i think we still haven't finished on this topic but it is somewhat important to move forward with our IP clearance and the whole development work. So if nobody has real objections i would like to move forward with this proposal but would also like to change the proposed directory name from ext_sources to 3rdparty. Keep in mind that we use this directory to keep the current state working and with our ongoing work we will remove more and more stuff from there. The adapted bootstrap mechanism will download the libraries from this new place. Juergen
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
2011/10/27 Jürgen Schmidt jogischm...@googlemail.com: On 9/22/11 1:19 PM, Jürgen Schmidt wrote: ok, we have several arguments for and against but no decision how we want to move forward. Let us take again a look on it 1. we have a working mechanism to get the externals from somewhere, check md5 sum, unpack, patch, build 1.1 somewhere is configurable during the configure step, initially the externals are downloaded from http://hg.services.openoffice.org/binaries 2. having the externals in the repository (SVN) won't be a big issue because in case of a checkout always the tip version is downloaded 2.1 the SCM can be used to track the used version of the externals for a specific OO version - simply checkout the version tag and everything is in place ... 3. in a DSCM it would be a real problem over time because of the increasing space of all versions 4. we need a replacement http://hg.services.openoffice.org/binaries asap (who knows how long the server will be available) 5. many developers probably work with a local clone of the repository using for example git svn or something else - disadvantage of the increasing space but probably acceptable if a clean local trunk will be kept and updated Proposed way to move forward 1. put the externals under .../trunk/ext_sources .../trunk/ext_sources .../trunk/main .../trunk/extras 2. adapt configure to use this as default, disable the download (maybe reactivate it later if we move to a DSCM) 3. keep the process with checking the md5 sum as it is (for potential later use) Any opinions or suggestions? i think we still haven't finished on this topic but it is somewhat important to move forward with our IP clearance and the whole development work. So if nobody has real objections i would like to move forward with this proposal but would also like to change the proposed directory name from ext_sources to 3rdparty. Keep in mind that we use this directory to keep the current state working and with our ongoing work we will remove more and more stuff from there. So keep the current approach with tarballs with MD5 hashnames, etc., just as before but on Apache servers? That sounds good to me. The adapted bootstrap mechanism will download the libraries from this new place. Juergen
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Regina, On 25.10.2011 18:33, Regina Henschel wrote: Hi Armin, Armin Le Grand schrieb: [..] I checked all changes again and added the patch to #118485#. Now I'm looking for someone volunteering to add the patch, build AOOo and play around with OLEs a little bit, reading the patch will also help in this case, it's not too big to do so. I did some further tests. Good, go ahead :-) Have You checked the converters? It's even possible to convert charts directly to Sdr-3D-Objects (but not nice) :-) You can directly substract e.g. an ellipse from a chart, too. In activated mode there should be no rot/shear and no green handles anymore (was an error anyways, modifying these while the OLE was activated leaded to unpredictable errors). Changing dimensions of the activated OLE will adapt to the centered OLE after deactivation as needed. I have taken some older documents, where the transformations are done via matrix (you know them). Chart and Math-Formulas behave now the same way as simple drawing objects. So that is OK. Good, thanks for checking. OOo sxd-documents are converted fine, the fill style and the line style is corrected to NONE. Yes, all OOo 3.4 are corrected at load time. In ODF, no attributes for fill and line are set, so the default blue8/hairline is what is defined in the ODF, just because it was not set to none in the OLE constructors. I added that for OOo 3.3 but it failed since ODF export goes over UNO API and fill/line was not allowed for OLEs (which I also changed now). The change looks big, but it touches no too critical parts. It is also necessary to bring it in AOOo3.4, this change relies on a version change (here: 3.3 to 3.4) to be able to correct files written by OOo up to 3.3 (and only those). Some background: The root problem here was that older versions straight ignored attributes set at OLE objects by just not painting them. This means that in files generated the attributes are written and in plain ODF OLEs are filled default (blue8) and have line on default (black hairline). Documents made with LibreOffice are not converted. The background is blue and the line black. Is a solution possible inside AOOo? Should it be done? Source of this is that LO already has 3.4 version and the correction would have to be done for LO = 3.4, plus writing OLEs with LINE_NONE and FILL_NONE if set (activating LineProperties/FillProperties for OLEs in LO, too). I'm already in contact with Thorsten and we are working on a solution for both together. I need to check if LO files can be detected and it looks like being possible. ODF exchange is very important for all of us, so there should be a correction in AOO at LO-created-file load time and mentioned corrections in LO, too. As described above, seen from ODF, OLEs are actually blue8 and hairline, so technically it's correctly displayed. Some other product using ODF FileFormat may have written such files where the OLEs are actually blue8 and hairline, so correction can only be done for known cases, e.g. OOo 3.4 and LO = 3.4 where we know for sure that the error was that the old paints just ignored LineStyle/FillStyle. I'm working on it with Thorsten, it's solvable... I have written a Basic macro to set the background and line style to NONE. Developing it I have noticed, that the Math-objects do not support the services LineProperties and FillProperties. But I can set the single properties 'LineStyle' and 'FillStyle' and Xray lists all the other properties. So shouldn't they support these services? Not sure. StarMath is a regular OLE, so it should support LineProperties and FillProperties. But not inside StarMath itself, it's supported in the SdrObject containing the StarMath. There may be exceptions in the old code for StarMath. It's also possible that You used it in Writer which has it's own OLE implementation and does not (yet) support those new features...? Questions/Comments are welcome, Armin Kind regards Regina Sincerely, Armin -- ALG
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
--- On Thu, 10/27/11, Jürgen Schmidt jogischm...@googlemail.com wrote: ... i think we still haven't finished on this topic but it is somewhat important to move forward with our IP clearance and the whole development work. So if nobody has real objections i would like to move forward with this proposal but would also like to change the proposed directory name from ext_sources to 3rdparty. Keep in mind that we use this directory to keep the current state working and with our ongoing work we will remove more and more stuff from there. I was about to bring in support for FreeBSD's fetch command (somewhat like curl) in fetch-tarballs.sh and it looks like now you are obsoleting it :-P . In any case, yes.. I think this is the way to go. I am just hoping there will be a way to opt out those components in favor of the system libraries when those available. Pedro.
Re: odt2braille on the Mac
On 10/27/11 6:12 PM, Ariel Constenla-Haile wrote: Hi Jürgen, On Thu, Oct 27, 2011 at 12:01:09PM +0200, Jürgen Schmidt wrote: Hi Bert, i assume it is again a threading issue on MacOS and the used Java API requires the main thread as well. I don't have a solution yet for you and i am not aware of any existing solution but we have to solve this issue anyway. But at the moment we have many other thinks to do with our ongoing IP clearance. But your extensions is quite interesting and of course very useful for probably many users. We can also think about a further UNO API to ask for the system default printer because the code should be available somewhere. it is already available in http://api.openoffice.org/docs/common/ref/com/sun/star/awt/XPrinterServer.html#getPrinterNames you are right, sometimes i got lost in our APIs especially when i haven't used it for some time ;-) Hopefully it helps Bert for the moment. Juergen
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
On 10/27/11 6:13 PM, Pedro Giffuni wrote: --- On Thu, 10/27/11, Jürgen Schmidtjogischm...@googlemail.com wrote: ... i think we still haven't finished on this topic but it is somewhat important to move forward with our IP clearance and the whole development work. So if nobody has real objections i would like to move forward with this proposal but would also like to change the proposed directory name from ext_sources to 3rdparty. Keep in mind that we use this directory to keep the current state working and with our ongoing work we will remove more and more stuff from there. I was about to bring in support for FreeBSD's fetch command (somewhat like curl) in fetch-tarballs.sh and it looks like now you are obsoleting it :-P . In any case, yes.. I think this is the way to go. I am just hoping there will be a way to opt out those components in favor of the system libraries when those available. me too but we should move forward and we can change it at any time when we have a better solution. Juergen Pedro.
Re: [DISCUSS] replace neon with libwww (preferred) or libcurl (as 2. choice)
Am 10/27/2011 07:01 PM, schrieb Jürgen Schmidt: On 10/27/11 5:55 PM, Jürgen Schmidt wrote: Hi, i will continue my evaluation of libwww [1] as a replacement for the neon library that we can't use in the future because of the LGPL license. libwww would be the preferred replacement because of the WebDAV support. Libwww is a highly modular, general-purpose client side Web API written in C for Unix and Windows (Win32). It's well suited for both small and large applications, like browser/editors, robots, batch tools, etc. Pluggable modules provided with libwww include complete HTTP/1.1 (with caching, pipelining, PUT, POST, Digest Authentication, deflate, etc), MySQL logging, FTP, HTML/4, XML (expat), RDF (SiRPAC), WebDAV, and much more. The license is BSD like and i was already in contact with one of the developers and they would be interested to grant it to Apache if there is enough interest to work on it in the future. It looks like an inactive project but they still receive patches from time to time and it is used in several projects. Well it is a complete implementation of a standard (HTTP 1.1) and besides bugfixes probably not too many things to do. Ok there is still room for improvements in some areas... Having such a HTTP client library written in C might be a good enhancement or extension of an existing Apache project. As far as i know there exists only Java based HTTP client libraries. Or as an own top level project if enough interested people are available. Anyway i will check if we can use it as a replacement for neon and based on the fact that it supports FTP as well, we can perhaps replace libcurl in then future too. But that is not so important at this time. If anybody is interested to help with this effort you are welcome. Beside the reimplementation of the WebDAV UCP (handles all http file access today) we have to integrate libwww in our build env as other external libs on all the supported platforms. If the evaluation fails and we can't use it we can use libcurl for plain http file access. And can later focus on WebDAV by using Apaches own stuff implemented in Java. Any opinions or objections others than Java is bad? after posting this i found some further info which let me rethinking this approach and i would like to ask 2 questions first. 1. Does anybody already have some experience with libwww? 2. How important do you think is WebDAV support in the future? - Nice to have as we had it before - Important because widely used - Not so important, we should better focus on CMIS integration I don't want spent time on the wrong things and libcurl is of course widely used, already available in our build env and well accepted. My initial approach was perhaps too much focused on not losing WebDAV support. [1] http://www.w3.org/Library/ If WebDAV is not necessary for CMIS implementation, then it is less important. The only nice feature I know is that you can load and save from network connections (e.g., FTP server). Would be great to keep this functionality but I don't know how bad it would be if future releases don't support this anymore. Marcus
Re: [DISCUSS] replace neon with libwww (preferred) or libcurl (as 2. choice)
--- On Thu, 10/27/11, Jürgen Schmidt jogischm...@googlemail.com wrote: ... after posting this i found some further info which let me rethinking this approach and i would like to ask 2 questions first. 1. Does anybody already have some experience with libwww? I have no experience but it is pretty popular, especially for perl packages. FreeBSD's ports tree has only a minor patch to ensure that it catches the system openssl. 2. How important do you think is WebDAV support in the future? - Nice to have as we had it before - Important because widely used - Not so important, we should better focus on CMIS integration I don't want spent time on the wrong things and libcurl is of course widely used, already available in our build env and well accepted. My initial approach was perhaps too much focused on not losing WebDAV support. I personally don't think its urgent. The glibc-stubs dependency is much more urgent IMHO. Pedro.
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
--- On Thu, 10/27/11, Jürgen Schmidt jogischm...@googlemail.com wrote: In any case, yes.. I think this is the way to go. I am just hoping there will be a way to opt out those components in favor of the system libraries when those available. me too but we should move forward and we can change it at any time when we have a better solution. I am OK with that, but let me attempt to dump what I think: 1) you are not bringing in *anything* copyleft, that directory will only be for the non-restrictive stuff that we need: ICU, Boost, etc. 2) This will all have to be registered in the NOTICE file, but since this is transitory and not really stuff we use in base, we should start a new section there to separate it from the stuff we do use in the core system. 3) We should probably move some of the stuff in soltools there too (mkdepend). 4) I know you want ucpp there too, but since that stuff is used in idlc, I think I'd prefer it in idlc/source/preproc/ as it was before. No idea if we can use the system cpp for the rest but that would probably make sense. All just IMHO, I am pretty sure whatever you do is better than what we have now :). Pedro.
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
On Thu, Oct 27, 2011 at 2:28 PM, Pedro Giffuni p...@apache.org wrote: --- On Thu, 10/27/11, Jürgen Schmidt jogischm...@googlemail.com wrote: In any case, yes.. I think this is the way to go. I am just hoping there will be a way to opt out those components in favor of the system libraries when those available. me too but we should move forward and we can change it at any time when we have a better solution. I am OK with that, but let me attempt to dump what I think: 1) you are not bringing in *anything* copyleft, that directory will only be for the non-restrictive stuff that we need: ICU, Boost, etc. I think it is like the SVN trunk. We initially bring it all in, and then remove the copyleft parts. Of course if we can remove them before hand, that is good as well. But whatever order we do the work, we cannot release until we've done the IP review. The files are currently hosted here: http://hg.services.openoffice.org/binaries/ Since the build currently depends on that, I think we want to move those files now, to Apache, rather than wait too long. -Rob 2) This will all have to be registered in the NOTICE file, but since this is transitory and not really stuff we use in base, we should start a new section there to separate it from the stuff we do use in the core system. 3) We should probably move some of the stuff in soltools there too (mkdepend). 4) I know you want ucpp there too, but since that stuff is used in idlc, I think I'd prefer it in idlc/source/preproc/ as it was before. No idea if we can use the system cpp for the rest but that would probably make sense. All just IMHO, I am pretty sure whatever you do is better than what we have now :). Pedro.
Re: [DISCUSS] replace neon with libwww (preferred) or libcurl (as 2. choice)
Haven't read the thread, but: Subversion can use the serf library (Apache Licensed) instead of neon.
[solved] Boost C++ source libraries are allowed to be used
Hi, the Boost C++ source libraries which we are using in our project can still be used under the Apache's rules. The Boost Software License Version 1.0 is now been classified as a category A license - see corresponding jira issue https://issues.apache.org/jira/browse/LEGAL-101 and http://www.apache.org/legal/resolved.html#category-a Best regards, Oliver
Re: [DISCUSS] replace neon with libwww (preferred) or libcurl (as 2. choice)
Aha!! http://code.google.com/p/serf/ It is based on the Apache Portable Runtime, which we discussed could be used as a replacement for the glibc-stubs functionality. I love it when pieces just fit in ;-). Pedro. --- On Thu, 10/27/11, Daniel Shahaf d...@daniel.shahaf.name wrote: Haven't read the thread, but: Subversion can use the serf library (Apache Licensed) instead of neon.
Re: [DISCUSS] replace neon with libwww (preferred) or libcurl (as 2. choice)
Hi Daniel; From what I understand, we only need getopt() and readdir_r() and basically only for Windows. There are Windows implementations for those but if it makes sense to use APR for other reasons (serf), much better. cheers, Pedro. --- On Thu, 10/27/11, Daniel Shahaf d...@daniel.shahaf.name wrote: From: Daniel Shahaf d...@daniel.shahaf.name Subject: Re: [DISCUSS] replace neon with libwww (preferred) or libcurl (as 2. choice) To: Pedro Giffuni p...@apache.org Cc: Jürgen Schmidt jogischm...@googlemail.com, ooo-dev@incubator.apache.org Date: Thursday, October 27, 2011, 2:24 PM I don't know what glibc-stubs is but have a look at libsvn_subr's public API too. (Basically https://svn.apache.org/repos/asf/subversion/trunk/subversion/include/ sans the header files whose name matches one of the directory siblings of include/; or just all the non-function static in ../libsvn_subr/) We have there a rather nice assortment of miscellaneous functions... Pedro Giffuni wrote on Thu, Oct 27, 2011 at 12:11:54 -0700: Aha!! http://code.google.com/p/serf/ It is based on the Apache Portable Runtime, which we discussed could be used as a replacement for the glibc-stubs functionality. I love it when pieces just fit in ;-). Pedro. --- On Thu, 10/27/11, Daniel Shahaf d...@daniel.shahaf.name wrote: Haven't read the thread, but: Subversion can use the serf library (Apache Licensed) instead of neon.
Re: Mailing list user migration: Staging and volunteers
On Wed, Oct 26, 2011 at 3:04 PM, Kay Schenk kay.sch...@gmail.com wrote: On Tue, Oct 25, 2011 at 2:43 PM, Rob Weir robw...@apache.org wrote: On Tue, Oct 25, 2011 at 5:36 PM, Kay Schenk kay.sch...@gmail.com wrote: On Tue, Oct 25, 2011 at 2:30 PM, Rob Weir robw...@apache.org wrote: A quick summary of where we are, in case you haven't been following the previous threads. Information on the top 100 legacy mailing lists is on the wiki [1]. A draft note that will be sent to these lists is an another page [2]. If you note in that first page, the Migration Owner column is blank. So either I need to quickly learn French, Dutch and Japanese, or I need some help here. Volunteers would translate the note, send it to the relevant NL lists, and be available on those lists to answer any migration-related questions. Ideally you would already be a participant on the lists and familiar to that community. As for staging, I'd recommend that we do not do this all at once. Migrating 100 lists at once would be very messy. But we can easily break this down into related groups of lists and do the migration over a few weeks. One possible staging would be: 1) All the lists that will be merged into the new ooo-marketing list. This will help jump start that lists important work, and bring community members into the discussion who might not have been interested in the other topics we've been discussing on ooo-dev. 2) All of the lists that will be merged into ooo-dev 3) All of the lists that will be merged into ooo-users 4) NL lists (which could be done in parallel with the above. However, they will require some discussion and admin work to create new ooo-lang lists,) The thought behind this staging is that we work out the kinks with the more technical and (hopefully) more forgiving project lists, before moving on to the user and NL lists. We can adjust the instructions and messaging based on what we learn from the initial migrations. Regards, -Rob Have the new NL lists been setup already? I may have missed that and I haven't look at any jira tix. No NL lists yet, except for Japanese. We need moderator volunteers before we can request them. Process for getting a new mailing list created is here: http://www.apache.org/dev/committers.html#new-mailing-list Probably makes sense to start with the largest NL communities first? [1] https://cwiki.apache.org/confluence/display/OOOUSERS/Mailing+lists [2] https://cwiki.apache.org/confluence/display/OOOUSERS/Email+Migration+Post -- --- MzK This is no social crisis Just another tricky day for you. -- Tricky Day, the Who OK. In terms of process, it's kind of a Catch-22 with the NL lists I guess. We can't have them without moderators, and it's unlikely we'll get (volunteer) moderators until we have them sigh. What to do... The ones in the first block on: https://cwiki.apache.org/confluence/display/OOOUSERS/Mailing+lists through website.dev should be good for the initial message you've got. And, I'm sure they're all English-speaking. Where are you with any of this? Do you need some of us to do subscriptions and get started? Maybe we could assign blocks from the first part of the page above? I'm happy to help. I don't have a lot of time on a daily basis, but could probably do at least 10 over the next few days. I would be happy to deal with sc.dev thru website.dev. I'll start on subscriptions to these pronto. IT might be a good idea if we decided to do the messaging on the same day though. Thoughts. I took ownership of the ones I'm working on. I hope to get notifications sent tomorrow to most, or by Sunday pm at the latest. -- --- MzK This is no social crisis Just another tricky day for you. -- Tricky Day, the Who -- --- MzK This is no social crisis Just another tricky day for you. -- Tricky Day, the Who
Re: handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
Hi Matthias; --- On Thu, 10/27/11, Mathias Bauer mathias_ba...@gmx.net wrote: ... In any case, yes.. I think this is the way to go. I am just hoping there will be a way to opt out those I am OK with that, but let me attempt to dump what I think: 1) you are not bringing in *anything* copyleft, that directory will only be for the non-restrictive stuff that we need: ICU, Boost, etc. That should be doable. OTOH I'm wondering whether we should keep the copyleft tarballs at Apache Extras - it would allow to still build with them (something that can be done outside the ASF infrastructure and is still appreciated (if I understood correctly). I don't like that but we will have to do it as a temporary solution to avoid breaking the build until we replace everything. I think on the long run this is only interesting for windows binaries, due to the difficulties of getting those packages from different places. On linux/BSD distributions it makes sense to use the prepackaged mozilla, etc. 3) We should probably move some of the stuff in soltools there too (mkdepend). That's something for later, ATM we should move the ext_src stuff into a secure place. Yes. Also for later, the simpleICC library is used to generate a color profile required for pdf. I think we should just generate the color profile somewhere outside the main build and use it, avoiding the extra build cycles. Another thing is we are excluding by default with extreme prejudice both LGPL and MPL but it will be convenient to reevaluate that since we will have to use the prepackaged hunspell. If nobody else wants to do it, I can invest some time into that, but it might take some days. I won't do it because of principles... I want them to just go away ;-). FWIW, Rob and I are trying to use an ooo- prefix on Apache Extras. ooo-external-sources ? It seems that the consensus is that we check in the binary tarballs into trunk/ext_sources?! I am not sure on that, I think lazy consensus by whomever does it first will win :). Pedro.
Header Project
I have started a wiki page to track the updating of the source headers. [1] I'll put a number of lists up there containing the files from the SGAs and sorted versions of the combined list. I'll be starting with some easy sets to get the process going and, hopefully, not break the build. Everyone is welcome to follow along at home - should be a ton of fun. 0 down 67834 to go Andrew 1 - https://cwiki.apache.org/confluence/display/OOOUSERS/Header+Project
Re: Shutdown of the download.services.openoffice.org host and its Mirrorbrain instance
Am 10/27/2011 11:36 AM, schrieb Gavin McDonald: -Original Message- From: Ross Gardler [mailto:rgard...@opendirective.com] Sent: Thursday, 27 October 2011 10:48 AM To: ooo-dev@incubator.apache.org Cc: Peter Pöml Subject: Re: Shutdown of the download.services.openoffice.org host and its Mirrorbrain instance Sent from my mobile device, please forgive errors and brevity. On Oct 27, 2011 1:22 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/27/2011 02:03 AM, schrieb Ross Gardler: Sent from my mobile device, please forgive errors and brevity. On Oct 27, 2011 12:37 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/26/2011 11:57 PM, schrieb Peter Pöml: Setting up MirrorBrain would be one way, but it would require replication additional configuration (for instance, download statistics) that we have built on the current download server (download.services.openoffice.org). Another way would be to simply have a virtual machine, where we move the current server to. That would cause the least effort, I guess. +1 this should be really our goal for now ... ... Starting from scratch would mean to lose a lot of the previos work -- and I really mean lots, which I dare to judge because I spent a lot of time with download.services.openoffice.org. On the other hand, having MirrorBrain at the core of the ASF's mirror system could be interesting for other projects, too. I know closer.cgi but I'm sure that MirrorBrain could serve the ASF well. (Well possible as an addition, rather than a replacement, for a soft transition.) That might outweigh the pain of creating OOo's download service from scratch in a different environment. ... and this the long term goal. The ASF can really benefit from this way of downloading software. Currently you have to choose a mirror, then change to the directory structure where the respective binary is located and finally download it. This is not correct. I have no idea if the ASF can benefit from MirrorBrain or not, but if your justification for such a statement is based on the above erroneous analysis of the current mirror system then I have my concerns. I OK, thats what I've done to come to my point: - browse to http://www.apache.org/; - click on Download top right - choose a mirror - change to the dir structure to your file - now download Is there an easier way to get software? E.g. http://httpd.apache.org/download.cgi#apache22 It auto selects the nearest mirror and provides appropriate download links - a single click. Want it pretty with big blue buttons? It's just HTML This was discussed early in the AOOo podlings existence.see archives for.more. I would like us to move on from this Topic, I have said before and I will say it again, ASF Infra will NOT support mirrorbrain. We have one mirror system and it deals with 200 or so projects. OpenOffice project will use the current ASF supported mirror system. End of story. If you see this like black and white then I can do this, too: If we don't get the support that AOO needs then we can outsource the download easily. EOD (yes, this wasn't meant seriously) It's sad that you brush it simply aside without to see the chance to at least try to improve things. Why OOo is special: - over 70 committers (more than 10x of other projects, right ?) - several millons of code lines - over 70 supported languages - 4 supported CPU architectures - 4 supported operating systems - OOo 3.3 consists of ~1.000 files with ~70 GB - in the peak with 300,000 downloads per day With these short facts IMHO everybody should be able to see that this is not just another project and that it needs special treatment when needed. Even when we won't get back the download numbers in the middle run due to the long silence of the last months and reduce the number by lets say 50% we would be still by far the largest ASF project. But you are right ... That said, let us get these other migrations done and we can see how/if the previous releases can be integrated. ... currently we have indeed other more important road works on the plan. Marcus
Re: Disposition of *.services.oo.o
Looking into this further - I believe that download.services.openoffice.org will not be affected. It should stay up along with all of the Kenai based services and svn.oo.o/hg Andrew On 10/27/2011 4:09 PM, Marcus (OOo) wrote: Am 10/22/2011 12:08 PM, schrieb Marcus (OOo): Am 10/22/2011 01:56 AM, schrieb Marcus (OOo): Am 10/22/2011 01:37 AM, schrieb Dave Fisher: On Oct 21, 2011, at 4:16 PM, Marcus (OOo) wrote: Am 10/21/2011 08:35 PM, schrieb Dave Fisher: (2) downloads.services.oo.o goes away this needs attention. This is the major unknown. We do have a version of this page in the website migration. It is rather clean. I think the page handles a missing mirror brain, but I don't know if it handles it well. The version that was cleaned up is in the AOOo project svn in ooo/ooo-site/trunk/content/download/. Yes, the complete download method rely on a working download.services.oo.o domain as here our Mirrorbrain instance is running to do the loadbalancing for download requests. As it wasn't accepted to bring this into the podling as another software service, we have to find another solution. 1) As short term solution we could switch to a system that we were allowed to use as backup for any outages we had at Sun/Oracle times. This system is running on www.mirrorbrain.org and is hosted and serviced by Peter Poeml. As long as the download.openoffice.org host is still working there shouldn't be bigger problems if we could use the backup system. I'll ask him if it's OK to rely this time a bit longer as long as we have not a long term solution (see other mail). 2) It seems to be time to connect to the ASF system to do software downloads. However, AFAIK we have the problem that the ASF is very likely not willing to host pre-ASF releases of OOo within their mirror network. Nevertheless we need to prepare our download webpages for the ASF method when we will have ready our first AOO release. It may be that we can use the ASF method of picking mirrors to select from the current list of OOo mirrors. I've not yet tested which ASF mirrors already provide also OOo install sets. Or how to change the script, so that it accepts also other mirrors. And the http://www.apache.org/dyn/closer.cgi; script has to be tweaked, so that it provides the suitable mirror *and* link to the OOo install set. Only a link to the closest mirror is not enough for end-users. A lot to do. However, for me this seems to be the long term solution. BTW: Here's the list of all OOo mirrors: http://download.services.openoffice.org/mirrors/all.html There is another host inside the *.services.oo.o domain. It's working as FTP master server for the complete mirror network. A few big mirrors sync from this master server to keep up-to-date with the release builds. All other mirrors are sync'ing from these few big ones. I don't know exactly but it could happen that the release builds get deleted because the master server is no longer reachable. I'll send a message to the old distribution.mirrors@, so that all mirror admins are warned that the master server will be shutdown and they should make sure that the OOo directory tree doesn't get deleted when the rsync job starts to fails next week. Hopefully this will still reach enough mirror admins to keep the mirror network stable somehow to satisfy future download requests. Marcus So far one 1 mirror admin in Switzerland had some doubts to keep the mirror alive but I hope to convinced him to do so. No feedback from others. Lets cross our fingers that enough mirrors will stay in the game. Marcus -- Andrew Rist | Interoperability Architect OracleCorporate Architecture Group Redwood Shores, CA | 650.506.9847
Re: Disposition of *.services.oo.o
Am 10/28/2011 01:18 AM, schrieb Andrew Rist: Looking into this further - I believe that download.services.openoffice.org will not be affected. It should stay up along with all of the Kenai based services and svn.oo.o/hg Ah, nice surprise. :-) However, we are prepared for the case. Thanks Marcus On 10/27/2011 4:09 PM, Marcus (OOo) wrote: Am 10/22/2011 12:08 PM, schrieb Marcus (OOo): Am 10/22/2011 01:56 AM, schrieb Marcus (OOo): Am 10/22/2011 01:37 AM, schrieb Dave Fisher: On Oct 21, 2011, at 4:16 PM, Marcus (OOo) wrote: Am 10/21/2011 08:35 PM, schrieb Dave Fisher: (2) downloads.services.oo.o goes away this needs attention. This is the major unknown. We do have a version of this page in the website migration. It is rather clean. I think the page handles a missing mirror brain, but I don't know if it handles it well. The version that was cleaned up is in the AOOo project svn in ooo/ooo-site/trunk/content/download/. Yes, the complete download method rely on a working download.services.oo.o domain as here our Mirrorbrain instance is running to do the loadbalancing for download requests. As it wasn't accepted to bring this into the podling as another software service, we have to find another solution. 1) As short term solution we could switch to a system that we were allowed to use as backup for any outages we had at Sun/Oracle times. This system is running on www.mirrorbrain.org and is hosted and serviced by Peter Poeml. As long as the download.openoffice.org host is still working there shouldn't be bigger problems if we could use the backup system. I'll ask him if it's OK to rely this time a bit longer as long as we have not a long term solution (see other mail). 2) It seems to be time to connect to the ASF system to do software downloads. However, AFAIK we have the problem that the ASF is very likely not willing to host pre-ASF releases of OOo within their mirror network. Nevertheless we need to prepare our download webpages for the ASF method when we will have ready our first AOO release. It may be that we can use the ASF method of picking mirrors to select from the current list of OOo mirrors. I've not yet tested which ASF mirrors already provide also OOo install sets. Or how to change the script, so that it accepts also other mirrors. And the http://www.apache.org/dyn/closer.cgi; script has to be tweaked, so that it provides the suitable mirror *and* link to the OOo install set. Only a link to the closest mirror is not enough for end-users. A lot to do. However, for me this seems to be the long term solution. BTW: Here's the list of all OOo mirrors: http://download.services.openoffice.org/mirrors/all.html There is another host inside the *.services.oo.o domain. It's working as FTP master server for the complete mirror network. A few big mirrors sync from this master server to keep up-to-date with the release builds. All other mirrors are sync'ing from these few big ones. I don't know exactly but it could happen that the release builds get deleted because the master server is no longer reachable. I'll send a message to the old distribution.mirrors@, so that all mirror admins are warned that the master server will be shutdown and they should make sure that the OOo directory tree doesn't get deleted when the rsync job starts to fails next week. Hopefully this will still reach enough mirror admins to keep the mirror network stable somehow to satisfy future download requests. Marcus So far one 1 mirror admin in Switzerland had some doubts to keep the mirror alive but I hope to convinced him to do so. No feedback from others. Lets cross our fingers that enough mirrors will stay in the game. Marcus
Re: svn commit: r1190021 - /incubator/ooo/trunk/main/configure.in
To further clarify.. I thought disabling it would be a good midpoint between removing it and keeping it. In anycase I think we must keep the option alive in the forseeable future. I see no hurry to take a decision and the patch is pretty small so it's easy to undo. How about we keep it like this for a while and we re-enable it by the default (lazy consensus again) before the release? regards, Pedro. --- On Thu, 10/27/11, Pedro Giffuni wrote: Hmm... I did say on another thread I was planning to disable it, and enable openldap. I didn't remove it (just disabled) and there was plenty of people wanting to see it go, so lazy consensus applied. Should I revert it? I think using or not binfilter is something that should be left to the distributors to decide, but I will accept to revert this if there are strong feelings about it. Pedro. --- On Thu, 10/27/11, Mathias Bauer mathias_ba...@gmx.net wrote: Hi, did I miss something? I can't remember that we decided to remove binfilter from the first AOOo release. And IMHO a default build without any configure settings should be what we want to release (at least it should be as close to that as possible). Regards, Mathias Am 27.10.2011 22:54, schrieb p...@apache.org: Author: pfg Date: Thu Oct 27 20:54:01 2011 New Revision: 1190021 URL: http://svn.apache.org/viewvc?rev=1190021view=rev Log: Disable legacy binfilter by default. Use --enable-binfilter in configure if you need them. Modified: incubator/ooo/trunk/main/configure.in Modified: incubator/ooo/trunk/main/configure.in URL: http://svn.apache.org/viewvc/incubator/ooo/trunk/main/configure.in?rev=1190021r1=1190020r2=1190021view=diff == --- incubator/ooo/trunk/main/configure.in (original) +++ incubator/ooo/trunk/main/configure.in Thu Oct 27 20:54:01 2011 @@ -286,8 +286,8 @@ AC_ARG_ENABLE(kde4, if you want to support both KDE3 and KDE4. ],,) AC_ARG_ENABLE(binfilter, -[ --disable-binfilter Disable legacy binary file formats filters -],,if ! test -d ./binfilter; then enable_binfilter=no; fi) +[ --enable-binfilter Enable legacy binary file formats filters +],,) AC_ARG_ENABLE(rpath, [ --disable-rpath Disable the use of relative paths in shared libraries ],,) @@ -1336,13 +1336,13 @@ dnl dnl Disable legacy binary file formats filters dnl === AC_MSG_CHECKING([whether to enable filters for legacy binary file formats (StarOffice 5.2)]) -if test $enable_binfilter = no; then - WITH_BINFILTER=NO - AC_MSG_RESULT([no]) -else +if test $enable_binfilter = yes; then WITH_BINFILTER=YES BUILD_TYPE=$BUILD_TYPE BINFILTER AC_MSG_RESULT([yes]) +else + WITH_BINFILTER=NO + AC_MSG_RESULT([no]) fi AC_SUBST(WITH_BINFILTER)
RE: Shutdown of the download.services.openoffice.org host and its Mirrorbrain instance
-Original Message- From: Marcus (OOo) [mailto:marcus.m...@wtnet.de] Sent: Friday, 28 October 2011 9:13 AM To: ooo-dev@incubator.apache.org Cc: Peter Pöml Subject: Re: Shutdown of the download.services.openoffice.org host and its Mirrorbrain instance Am 10/27/2011 11:36 AM, schrieb Gavin McDonald: -Original Message- From: Ross Gardler [mailto:rgard...@opendirective.com] Sent: Thursday, 27 October 2011 10:48 AM To: ooo-dev@incubator.apache.org Cc: Peter Pöml Subject: Re: Shutdown of the download.services.openoffice.org host and its Mirrorbrain instance Sent from my mobile device, please forgive errors and brevity. On Oct 27, 2011 1:22 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/27/2011 02:03 AM, schrieb Ross Gardler: Sent from my mobile device, please forgive errors and brevity. On Oct 27, 2011 12:37 AM, Marcus (OOo)marcus.m...@wtnet.de wrote: Am 10/26/2011 11:57 PM, schrieb Peter Pöml: Setting up MirrorBrain would be one way, but it would require replication additional configuration (for instance, download statistics) that we have built on the current download server (download.services.openoffice.org). Another way would be to simply have a virtual machine, where we move the current server to. That would cause the least effort, I guess. +1 this should be really our goal for now ... ... Starting from scratch would mean to lose a lot of the previos work -- and I really mean lots, which I dare to judge because I spent a lot of time with download.services.openoffice.org. On the other hand, having MirrorBrain at the core of the ASF's mirror system could be interesting for other projects, too. I know closer.cgi but I'm sure that MirrorBrain could serve the ASF well. (Well possible as an addition, rather than a replacement, for a soft transition.) That might outweigh the pain of creating OOo's download service from scratch in a different environment. ... and this the long term goal. The ASF can really benefit from this way of downloading software. Currently you have to choose a mirror, then change to the directory structure where the respective binary is located and finally download it. This is not correct. I have no idea if the ASF can benefit from MirrorBrain or not, but if your justification for such a statement is based on the above erroneous analysis of the current mirror system then I have my concerns. I OK, thats what I've done to come to my point: - browse to http://www.apache.org/; - click on Download top right - choose a mirror - change to the dir structure to your file - now download Is there an easier way to get software? E.g. http://httpd.apache.org/download.cgi#apache22 It auto selects the nearest mirror and provides appropriate download links - a single click. Want it pretty with big blue buttons? It's just HTML This was discussed early in the AOOo podlings existence.see archives for.more. I would like us to move on from this Topic, I have said before and I will say it again, ASF Infra will NOT support mirrorbrain. We have one mirror system and it deals with 200 or so projects. OpenOffice project will use the current ASF supported mirror system. End of story. If you see this like black and white then I can do this, too: If we don't get the support that AOO needs then we can outsource the download easily. EOD (yes, this wasn't meant seriously) It's sad that you brush it simply aside without to see the chance to at least try to improve things. Excuse me? I am doing quite a lot already thank you. You do not our infrastructure or how it works, I do. Why OOo is special: - over 70 committers (more than 10x of other projects, right ?) Wrong Subversion 66 hadoop 64 commons 103 lucene 61 cocoon 81 Geronimo 64 Shall I go on, 10x other projects where on earth did you pull that gem from? - several millons of code lines LOC does not make a project special. Perhaps as things improve with efficiency those will come down. - over 70 supported languages Other project support other languages too. - 4 supported CPU architectures Some projects support more than that, your point is? - 4 supported operating systems Some projects support more than that, your point is? - OOo 3.3 consists of ~1.000 files with ~70 GB Correct. - in the peak with 300,000 downloads per day Thats fine. The mirrors will handle that. With these short facts IMHO everybody should be able to see that this is not just another project and that it needs special treatment when needed. sorry, you already are getting special treatment in other ways, but if every Tom Dick and Sally from this project got exactly what they asked for, they would also be paying for more servers, more bandwidth and more people to look after it all. Does everything in this
