[QA Report]Weekly report

[Ji Yan]

Hi all,

 I put QA weekly report in [1]. also defect status report in [2]. Please
review.

[1]http://wiki.openoffice.org/wiki/QA/Report/WeeklyReport/20120827
[2]http://wiki.openoffice.org/wiki/QA/Report/DefectStatus/20120827

-- 


Thanks & Best Regards, Yan Ji

Re: Re: The translation of AOO3.4.1 release notes and announcement

[eric wu]

hi:
I have finished the translation of the release notes,please check the 
attachments.thank you!




eric wu

From: Shenfeng Liu
Date: 2012-08-27 14:09
To: ooo-dev
Subject: Re: Re: The translation of AOO3.4.1 release notes and announcement
Kay and Eric,
  I suggest to put the release notes translation to:
http://www.openoffice.org/zh-cn/releases/3.4.1.html . (need to create the
folder "releases")

- Simon


2012/8/25 Kay Schenk 

> On Thu, Aug 23, 2012 at 7:04 PM, eric wu  wrote:
>
> > hi :
> > I have finished my translation of the release notes,but i don't know what
> > format to save my translation and how to put the translation under:
> > http://www.openoffice.org/zh-cn/, can you help me ?thank you!
> >
> >
> >
> >
> > eric wu
> >
>
> Hi eric --
>
> Ok, a bit of a problem.  Your translation, while good work, is set up to
> actually overwrite the current Release Notes in English where they
> currently reside, so we will not commit this change.
>
> So, I think what will need to happen is you (or someone) needs to determine
> where in/on this new page, your translated release notes will live. Go
> there and setup for a new page in an area, and then submit the translation
> to that NEW area so you don't overwrite the existing English copy.
>
> I know how to do this in normal svn but I'm not sure how to go about some
> of this using the CMS bookmarklet if you want to know the truth.
>
> Maybe someone else can weigh in here.
>
> First, though, maybe some additional coordination about where to locate
> this.
>
> I hope this helps.
>
>
> > From: Shenfeng Liu
> > Date: 2012-08-21 14:02
> > To: ooo-dev; jinjin.wu
> > Subject: Re: The translation of AOO3.4.1 release notes and announcement
> > Eric,
> >   That's great!
> >   You can find the current AOO 3.4.1 release draft by Kay Schenk in
> > English here: http://www.openoffice.org/development/releases/3.4.1.html.
> > I'm not sure if any further editing will be make on it.
> >
> >   And I think it will be better to put the translation some where under
> > http://www.openoffice.org/zh-cn/ . (Any better suggestion?)
> >
> >   The way should be copy the English release notes to the folder of
> zh-cn,
> > then translate it into a Chinese version. But currently we are freezing
> the
> > web waiting for the release, so I guess we can not update the contents
> > directly now. Maybe you can prepare for your translations, and after the
> > release, we can publish it immediately.
> >   Thanks!
> >
> > - Simon
> >
> >
> >
> > 2012/8/21 eric wu 
> >
> > Hi all:
> > I am from China Standard Software Co., Ltd.(cs2c), as a chinese apache
> > open office user,i am looking forward to assume the task of translation
> of
> >  AOO3.4.1 release notes and announcement .
> >
> >
> >
> >
> > eric wu
>
>
>
>
> --
>
> 
> MzK
>
> "As a child my family's menu consisted of two choices:
> take it or leave it. "
>-- Buddy Hackett
>

Re: Re: The translation of AOO3.4.1 release notes and announcement

[Shenfeng Liu]

Kay and Eric,
  I suggest to put the release notes translation to:
http://www.openoffice.org/zh-cn/releases/3.4.1.html . (need to create the
folder "releases")

- Simon


2012/8/25 Kay Schenk 

> On Thu, Aug 23, 2012 at 7:04 PM, eric wu  wrote:
>
> > hi :
> > I have finished my translation of the release notes,but i don't know what
> > format to save my translation and how to put the translation under:
> > http://www.openoffice.org/zh-cn/, can you help me ?thank you!
> >
> >
> >
> >
> > eric wu
> >
>
> Hi eric --
>
> Ok, a bit of a problem.  Your translation, while good work, is set up to
> actually overwrite the current Release Notes in English where they
> currently reside, so we will not commit this change.
>
> So, I think what will need to happen is you (or someone) needs to determine
> where in/on this new page, your translated release notes will live. Go
> there and setup for a new page in an area, and then submit the translation
> to that NEW area so you don't overwrite the existing English copy.
>
> I know how to do this in normal svn but I'm not sure how to go about some
> of this using the CMS bookmarklet if you want to know the truth.
>
> Maybe someone else can weigh in here.
>
> First, though, maybe some additional coordination about where to locate
> this.
>
> I hope this helps.
>
>
> > From: Shenfeng Liu
> > Date: 2012-08-21 14:02
> > To: ooo-dev; jinjin.wu
> > Subject: Re: The translation of AOO3.4.1 release notes and announcement
> > Eric,
> >   That's great!
> >   You can find the current AOO 3.4.1 release draft by Kay Schenk in
> > English here: http://www.openoffice.org/development/releases/3.4.1.html.
> > I'm not sure if any further editing will be make on it.
> >
> >   And I think it will be better to put the translation some where under
> > http://www.openoffice.org/zh-cn/ . (Any better suggestion?)
> >
> >   The way should be copy the English release notes to the folder of
> zh-cn,
> > then translate it into a Chinese version. But currently we are freezing
> the
> > web waiting for the release, so I guess we can not update the contents
> > directly now. Maybe you can prepare for your translations, and after the
> > release, we can publish it immediately.
> >   Thanks!
> >
> > - Simon
> >
> >
> >
> > 2012/8/21 eric wu 
> >
> > Hi all:
> > I am from China Standard Software Co., Ltd.(cs2c), as a chinese apache
> > open office user,i am looking forward to assume the task of translation
> of
> >  AOO3.4.1 release notes and announcement .
> >
> >
> >
> >
> > eric wu
>
>
>
>
> --
>
> 
> MzK
>
> "As a child my family's menu consisted of two choices:
> take it or leave it. "
>-- Buddy Hackett
>

Re: CMS diff: Why OpenOffice.org: Public administrations

[Shenfeng Liu]

Michal,
  I just verified them. Thanks very much!

- Shenfeng


2012/8/26 Michal Hriň 

> Shenfeng,
>
> I published yours latest patches (which you send here 6 days ago).
>
> Thanks.
> Michal Hriň
>
>
> Dňa Mon, 20 Aug 2012 04:18:50 +0200 Rob Weir  napísal:
>
>
>  On Sun, Aug 19, 2012 at 9:58 PM, Shenfeng Liu  wrote:
>>
>>> Rob,
>>>   That's my translations to the existing website materials. So it is no
>>> problem to wait to publish together with our announcement.
>>>
>>>
>> When using the CMS a publish operation is "all or nothing".  So if we
>> publish your changes then we also need to publish any other changes
>> that are pending on the staging server.  Since we are preparing to
>> announce the 3.4.1 release we are starting to load
>> announcement-related changes onto the staging server.  But we're not
>> ready to publish them yet.
>>
>> So my note was just to remind other committers that it is OK to commit
>> your changes and get them onto the staging server, but to wait for
>> publishing them.
>>
>> -Rob
>>
>>  - Shenfeng
>>>
>>>
>>> 2012/8/19 Rob Weir 
>>>
>>>  Let's be careful.  Don't we already have some announcement changes on
 staging?  If so we can bring this change as well onto staging, but we
 should avoid publishing, since that is all-or-nothing, and we don't
 want to put the announcement changes out yet.

 -Rob

 On Sun, Aug 19, 2012 at 11:28 AM, Shenfeng Liu 
 wrote:
 > Clone URL (Committers only):
 >
 https://cms.apache.org/**redirect?new=anonymous;action=**
 diff;uri=http://ooo-site.**apache.org/zh-cn%2Fwhy%2Fwhy_**gov.mdtext
 >
 > Shenfeng Liu
 >
 > Index: trunk/content/zh-cn/why/why_**gov.mdtext
 > ==**==**
 ===
 > --- trunk/content/zh-cn/why/why_**gov.mdtext  (revision 1374681)
 > +++ trunk/content/zh-cn/why/why_**gov.mdtext  (working copy)
 > @@ -1,4 +1,4 @@
 > -Title: Why OpenOffice.org: Public administrations
 > +Title: 为何选择Apache OpenOffice：公共管理
 >  Notice:Licensed to the Apache Software Foundation (ASF) under one
 > or more contributor license agreements.  See the NOTICE
 file
 > distributed with this work for additional information
 > @@ -16,20 +16,20 @@
 > specific language governing permissions and limitations
 > under the License.
 >
 > -![Why Apache OpenOffice: Public
 administrations](/why/images/**why_gov.png) # {.rfloatimg}
 > +![为何选择Apache OpenOffice：公共管理](/why/images/**why_gov.png) #
 {.rfloatimg}
 >
 > -Public administrations and people working at **all levels of
 government** (local / federal / regional / national etc) find Apache
 OpenOffice is their ideal software solution. The combination of a
 **flexible word processor**, a **powerful spreadsheet**, **dynamic
 graphics**, **database access** and more meets all the everyday needs
 of a
 typical busy office worker.
 > +公共管理单位以及为**各级政府机关**工作的人（**无论是地方的还是中央的，区域性的还是全国性的）**都会发现Apache
 OpenOffice是他们理想的软件解决方案。**它的组合中包含一个**灵活的文本编辑器**，一个
 强大的电子表格**，**灵活的绘图**，**数据库访问等等，可以满足一个忙碌的办公室工作人员的所有日常办公需求。
 >
 > -Already available in a **wide range of languages**, OpenOffice can be
 freely translated by local teams.
 > +OpenOffice可以被本地团队自由地翻译，所以拥有许多不同的语言包**。
 >
 > -  - **Best value**
 > +  - **价值最大化**
 >
 > -Using Apache OpenOffice demonstrates your commitment to deliver
 best value services. It is not owned by any commercial organisation. Its
 open source licence means there are no licence fees to pay, no expensive
 annual audits, and no worries about non-compliance with onerous and
 obscure
 licencing conditions. You may also distribute the software free to your
 employees, through the schools system, or any other channel of your
 choice.
 > +使用Apache
 OpenOffice可以帮助你实现服务价值最大化的承诺。**它不被任何商业组织所拥有。**它的开源许可协议意味着没有许可证费，没有昂贵的年审，
 **并且不用担心违反那些繁琐而又模糊不清的许可协议条款。**你还可以通过教育系统或任何你选择的途径将这个软件免费分发到你**的员工手里。
 >
 > -  - **Data is safe**
 > +  - **数据安全保证**
 >
 > -Freedom of Information Acts require that the documents you create
 today will be accessible years in the future. Apache OpenOffice is the
 first software in the world to use ISO approved file formats as its
 default. It also has the ability to create PDF files if you need to
 publish
 information in a standard 'read only' format. If you already have
 (possibly
 unlicenced) office software, Apache OpenOffice should be able to read
 your
 old files.
 > +信息自由法案要求你今天所创建的文档在未来几年内都可以被访问。**Apache
 OpenOffice是世界上第一款使用ISO批准的标准文件格**式作为缺省格式的软件。如果你需要通过标准的“只读”**
 格式发布信息，它同样可以创建PDF文件来满足你的要求。**如果你已经有了办公软件（也许不是正版的？），Apache
>>

Propose to support import Shape in VML format from MS OOXML file

[Ying Zhang]

Hi, All

Shape is a very important feature for writer, but AOO does not support
import Shape defined in OOXML file of docx file especially, and which will
be lost after import the docx file in AOO.
I propose to support import shape in VML format in docx file into AOO and
put them as candidates for next release and for your comments.
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Planning

Background:
Shape, as well as Text Box as a kind of shape, described in OOXML as VML
format and DrawingML format:
1> In Word 2007, the VML format is used as only language for shape
description; and in Word 2010, it use both VML format and DrawingML format
as shape's markup language, which means, for one shape in docx file created
in word 2010, we can get the shape's description both in VML format and
DrawingML format;
2> In Powerpoint 2007/2010 and Excel 2007/2010, the shape use the DrawingML
as markup language, and for some other objects, like: Commnets, etc. are
described in VML format. And AOO support shapes in pptx file and xlsx file
in DrawingML format, and partial of VML format parsing like xlsx comments.

Based on the information, we plan to support Word 2007/2010 shape's import
in VML format first to improve the interoperability with MS Office
2007/2010, and the scope including:
1> Support the load-show for the VML shape, including textbox, from docx
file;
2> Support to import more shape's property, like: background, border, font,
etc;

Re: [Discuss] Triage of Brainstorming

[Kevin Grignon]

KG01 see comments inline.

On Aug 24, 2012, at 11:39 PM, drew  wrote:

> On Fri, 2012-08-24 at 15:58 +0100, Rory O'Farrell wrote:
>> On Fri, 24 Aug 2012 07:49:02 -0700
>> Dave Fisher  wrote:
>>
>>>
>>> On Aug 24, 2012, at 7:39 AM, Rob Weir wrote:
>>>
 On Fri, Aug 24, 2012 at 8:31 AM, Rory O'Farrell  wrote:
>
> In due course, when we've all had a little rest after the release of AOO 
> 3.4.1, it will be necessary to do some triage work on the Brainstorming, 
> so that the most requested changes make their way onto the planning table 
> for AOO 4.0.  Many of the suggestions can be amalgamated, for example 
> improved doc/docx, xls/xlsx etc support; within reason these can all be 
> amalgamated into "improved support for MS Office formats, current and 
> legacy".  Other suggestions are readily achievable by existing faciites 
> in OpenOffice; such requests might indicate need for better education of 
> Users or more accessible documentation/tutorials.

> Supposing that the Brainstorm is continued beyond AOO 4.0, should we 
> prune it in the light of whatever choices are made for AOO 4.0; should we 
> also register comments against some of the already readily achievable 
> functions, to give pointers to (say) the Forums and/or tutorials which 
> indicate how to do that function?
>

KG01 - Yes, tracing discussion and voting results to a list if
prioritized reqs is import. Furthermore, we need to then trace the
reqs to design explorations (including scenarios and storyboards with
mockups).

> Could we have some discussion on how best to analyse and progress the 
> current nearly 300 suggestions [as of date of posting)
>


KG01 - We could bring our initial list of candidates to the upcoming
conference for further validation and prioritization.


 We're getting a lot more feedback than I expected:  305 people have
 submitted 284 ideas and cast 3,106 votes.

 IMHO, this is wonderful.   In some sense the voting process itself
 helps triage, especially if project members are also submitting ideas
 and voting, which I hope we all are.
>>>
>>> Not all of us have the time.

 I like your idea of combining closely related or duplicate ideas.
 Maybe in the end we could promote a "top 10" list of ideas, in a blog
 post, and collect also commentary from project members related to
 these top 10 ideas.
>>>
>>> I think that coming back to ooo-dev with "Top" ideas is appropriate.
>>
>> One of my concerns was that the multiple requests for similar 
>> features/support might cause these to drop off the radar as their voting 
>> would be too fragmented.  Hence my suggestion that we consider amalgamation 
>> of closely related suggestions; the coding for one specific suggestion might 
>> easily expand to cover the coding necessary for a particular range.  Hence 
>> the need for some form of triage to make best use of coding resources.
>
> Hi,
>
> Yes - I would agree, there will need to be some form of triage (call it
> moderation if you prefer).
>
> //drew
>
>>
>>>

 Another approach would be to take the top ideas and use them as
 additional input to a survey design that Kevin and Graham were looking
 into.  We could take the top 10 (or 20) ideas and in the survey ask
 users to rate them.
>>>
>>> FYI - The ASF Board has created a new TLP called Apache Steve which will 
>>> expose the Voting mechanism used by the ASF membership.
>>>
>>> Regards,
>>> Dave
>>>

 That help us get around the natural bias of Google Moderator, which is
 that ideas submitted first will get more votes because they've had
 more time to be voted on.

 Regards,

 -Rob

> --
> Rory O'Farrell 
>>>
>>>
>>
>>
>
>

Re: Unofficial Apache OO Debian repository updated

[Greg Madden]

On Sun, Aug 26, 2012 at 1:42 PM, Greg Madden  wrote:
> On Sun, Aug 26, 2012 at 12:47 PM, Wolf Halton  wrote:
>> Sounds like it might not take too much effort to get it to work in Ubuntu.
>>
>> Wolf Halton
>> http://sourcefreedom.com
>> Apache developer:
>> wolfhal...@apache.org
>> On Aug 24, 2012 4:37 PM, "Marcelo Santana"  wrote:
>>
>>> On Sat, 25 Aug 2012 03:45:38 +0800, imacat 
>>> wrote:
>>>
>>> [...]
>>>
>>> Hi there,
>>>
>>> > Hmm... in that case, shouldn't these package files work on
>>> > Squeeze, too?  Why is Wheezy?  Wheezy is not released yet.
>>>
>>> I'm not sure, but probably yes because there is no package dependency
>>> which prevent it to be installed on the squeeze. But I've not tested
>>> yet.
>
> I am a Debian user. I switched to AOO a while back because of a
> regression in LO that affects my work. I have been using the dev
> builds, works greatthanks.
>
> I am testing Wheezy in a VM , tried the sourceforge Debian repo's. The
> issue I am seeing is Debian still uses 'openoffice'  in their package
> management systems. Trying to find/install  openoffice results in
> links to libreoffice.

My mistake, wrong sources.list entry.

>
> While this is probable an issue to discuss with Debian, I am wondering
> how this repo is working for others.  What is the package name to
> install AOO ?

I now see it is openoffice.org3.

Debian, Wheezy , does use 'openoffice.org though.

-- 
Peace

Greg Madden

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Ross Gardler]

Some people "think", others have stayed clearly and unambiguously.
Including mentors who have voted on your binary release.

If the peanut gallery it's a confused then educate, don't argue. As for
those demanding a policy, I repeat my original statement - patches welcome.

The arguments are pointless.

You want precision. You have it. It's in the thread. You we given a clear
and direct response to your proposal. Don't tell me to read the thread
again. I already wasted my time reading it twice. As well as time spent
reviewing the AOO release.

Draw out the clarity that exists then, if necessary, go to legal@ with
three remainder.

Continuing to argue is a waste if time.

>From a mobile device - forgive errors and terseness
On Aug 26, 2012 10:17 AM, "Rob Weir"  wrote:

> On Sun, Aug 26, 2012 at 7:46 AM, Ross Gardler
>  wrote:
> > Moving back to AOO lists
> >
> > These argument is a waste of everyones time. It seems to me that what
> is/is
> > not permissible is clear, indeed has been clear for some time.the summary
> > is... Patches welcome.
> >
>
> Clear to some, but obviously not clear to others on the IPMC, since
> some are suggesting that this podling is not in conformance with ASF
> policy with regard to releases.
>
> > More importantly...
> >
> > As for some members of the AOO PPMC implying this is all new to them
> > because it is not documented in precise language is frankly insulting to
> > mentors whom have worked hard to communicate release policy around
> binaries.
> >
>
> Ross you should read the entire thread.  You'll find that some on the
> IPMC are suggesting that there is more to policy that what you or Joe
> think there is.
>
> I'm trying to figure out exactly what that delta is.  If you have
> anything constructive to add, I'm sure it would be appreciated.
>
> It is one thing to have an unwritten policy, it is another to have
> vastly different interpretations of what that policy is.  For
> something as critical as defining what a release is, since there are
> clearly differences of opinion, it is probably time to raise it above
> the level of folklore, and write it down.  No one should be genuinely
> insulted by a request that what is claimed as ASF policy be written
> down, especially if someone has already volunteered to do the
> drafting.
>
> In any case I now count four people on the IPMC list who are
> suggesting that we need a written policy in this area, to remove
> ambiguity.
>
> > Individuals arguing against those who know the ASF well, and are
> supported
> > by the vast majority of community commentators (including those opting to
> > stay silent because their points have been made), are not demonstrating
> > their ability to work in a collaborative, constructive project
> environment.
> >
> > When creating a PMC we are looking for people who can resolve conflict,
> not
> > make conflict. PMC members need to be constructive not obstructive. A
> > failure to recognise the difference is a demonstration of a failure to
> > understand how ASF projects work. PMC membership does not empower people
> to
> > contribute to the code, it empowers them to ensure the community is
> healthy.
> >
>
> IMHO it is very constructive in a disagreement to at least identify,
> with some precision, what it is that we are disagreeing about.
> Until that occurs, we're just going in circles.  So far I'm the only
> one in that thread who has put forward a constructive proposal for
> this language, and asked if there was anything to add.
>
> -Rob
>
> > The style of argumentation on this topic is, in some cases, destructive
> not
> > constructive. I'm not replying to a specific mail or individual, I'm
> simply
> > asking people to consider whether sending another email is constructive
> or
> > destructive. Is it possible to put that time into a constructive patch
> > instead?
> >
> > Ross
> > On Aug 26, 2012 7:26 AM, "Branko Čibej"  wrote:
> >
> >> On 26.08.2012 13:15, Tim Williams wrote:
> >> > Marvin gave the link earlier in this thread. 4th para is the relevant
> >> bit.
> >> >
> >> > http://www.apache.org/dev/release.html#what
> >>
> >> The relevant part is in the last paragraph. However, that says
> >> "convenience" and defines version numbering requirements, but it does
> >> /not/ state that the binaries are not sanctioned by the ASF and are not
> >> part of the official ASF release.
> >>
> >> It would be very useful if that paragraph were amended to say so
> >> explicitly. I've had no end of trouble trying to explain to managers and
> >> customers that any binaries that come from the ASF are not "official".
> >> Regardless of the policy stated numerous times in this thread and on
> >> this list, this is not clear anywhere in the bylaws or other online
> >> documentation (that I can find).
> >>
> >> -- Brane
> >>
> >> P.S.: I asked this same question on legal-discuss a week ago. My post
> >> has not even been moderated through as of today, so referring people to
> >> that list doesn't appear to be to

Re: [DL Website] Prototype of an automatic table with download links

[Marcus (OOo)]

Am 08/27/2012 12:12 AM, schrieb Dave Fisher:


On Aug 26, 2012, at 2:59 PM, Marcus (OOo) wrote:


Am 08/26/2012 11:37 PM, schrieb Marcus (OOo):

Am 08/26/2012 09:38 PM, schrieb Dave Fisher:


On Aug 26, 2012, at 11:05 AM, Marcus (OOo) wrote:


Hi all,

as promized on Friday I've adjusted the existing automatism to the
lastest AOO 3.4.1 parameters.

The most recent webpage is here:
http://ooo-site.staging.apache.org/download/test/other_print.html


There is one change needed with the source downloads. Please use the
Apache Mirrors and not dist directly for the packages. See [1].


Only for the source files, not for the hash files, right? Done.


Should the language packs be mixed with the full installation sets? If
so then maybe the language fields should span two rows?


To have all in a single table it's easier to point the user to resp. the
user has only to remember this.

I'll think about the span thing.


As "fast solution" I've deleted every second language strings and expanded the 
row highlighting.

Dave, what do you think?


Much better.

Maybe the go back to the top break in the language group should be more 
frequent than every 10?


Ah, right. With the combined table (full install, langpacks, hashes) 
it's still after 10 languages but actually a lot of big rows more which 
is indeed to much. I'll change it tomorrow.


Marcus




[1] http://incubator.apache.org/openofficeorg/downloads.html


I'm open for opinions. Otherwise I can put it easily to the
production website as the new "other.html".

RE: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst

[Dennis E. Hamilton]

I concur with Rob's analysis here (quoted below).

It occurs to me that there is another spanner in the works.  This will impact 
whatever the signing process is.

Namely: Not only does the installer need to be signed, but those *installed* 
components (e.g., .exe and .dll files) that can bear embedded, OS-recognized 
signatures need to be signed if products of the build from source.  In the case 
of bundled third-party components that are installed as-is, they may need to be 
signed by their originator as well.

This is part of the authenticity provision.  It has an important provision in 
determining whether or not a component has been altered or replaced after 
installation.  (In the case of drivers and other components, the OS may be 
fussier than that.)  This is also important if component-level replacement by 
patches is introduced.

I don't know that all of this has to be swallowed at once.  I is going to be a 
factor in the future and it would be good to take preparatory action.  

I expect that the bar will be raised on extensions too, and that might be 
handled by upgrading .oxt to use ODF 1.2 packaging, relying on the digital 
signature provisions that are already there for packages and special components 
such as scripts and macros.

 - Dennis

-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Sunday, August 26, 2012 13:47
To: ooo-dev@incubator.apache.org
Subject: Re: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst


[ ... ]

My point is that if we seek to have build-bot automated signed
binaries it is entirely foreseeable that what we're proposing to do
with 3rd party dependencies will also be out of policy, due to the
security concerns.  To do this we'll need to do more than just link to
random sites on the web for dependencies.

[ ... ]

Look at Andre's note from August 3rd.   First locations searched for
dependencies is the original website where it is hosted.  Then it
checks Apache Extras.  Then it checks SVN.   Taking SVN out of the
loop solves one issue.  But we still have the other issue -- I think
Dennis groks this as well -- that our primary search location is less
secure than the alternatives.

[ ... ], two relatively simple improvements:

1) Search Apache Extras first

or

2) Have the current script verify a detached signature rather than
relying on MD5 hashes


[ ... ]

Re: [DL Website] Prototype of an automatic table with download links

[Dave Fisher]

On Aug 26, 2012, at 2:59 PM, Marcus (OOo) wrote:

> Am 08/26/2012 11:37 PM, schrieb Marcus (OOo):
>> Am 08/26/2012 09:38 PM, schrieb Dave Fisher:
>>> 
>>> On Aug 26, 2012, at 11:05 AM, Marcus (OOo) wrote:
>>> 
 Hi all,
 
 as promized on Friday I've adjusted the existing automatism to the
 lastest AOO 3.4.1 parameters.
 
 The most recent webpage is here:
 http://ooo-site.staging.apache.org/download/test/other_print.html
>>> 
>>> There is one change needed with the source downloads. Please use the
>>> Apache Mirrors and not dist directly for the packages. See [1].
>> 
>> Only for the source files, not for the hash files, right? Done.
>> 
>>> Should the language packs be mixed with the full installation sets? If
>>> so then maybe the language fields should span two rows?
>> 
>> To have all in a single table it's easier to point the user to resp. the
>> user has only to remember this.
>> 
>> I'll think about the span thing.
> 
> As "fast solution" I've deleted every second language strings and expanded 
> the row highlighting.
> 
> Dave, what do you think?

Much better.

Maybe the go back to the top break in the language group should be more 
frequent than every 10?

Regards,
Dave

> 
> Marcus
> 
> 
> 
>>> [1] http://incubator.apache.org/openofficeorg/downloads.html
>>> 
 I'm open for opinions. Otherwise I can put it easily to the
 production website as the new "other.html".

Re: [DL Website] Prototype of an automatic table with download links

[Marcus (OOo)]

Am 08/26/2012 11:37 PM, schrieb Marcus (OOo):

Am 08/26/2012 09:38 PM, schrieb Dave Fisher:


On Aug 26, 2012, at 11:05 AM, Marcus (OOo) wrote:


Hi all,

as promized on Friday I've adjusted the existing automatism to the
lastest AOO 3.4.1 parameters.

The most recent webpage is here:
http://ooo-site.staging.apache.org/download/test/other_print.html


There is one change needed with the source downloads. Please use the
Apache Mirrors and not dist directly for the packages. See [1].


Only for the source files, not for the hash files, right? Done.


Should the language packs be mixed with the full installation sets? If
so then maybe the language fields should span two rows?


To have all in a single table it's easier to point the user to resp. the
user has only to remember this.

I'll think about the span thing.


As "fast solution" I've deleted every second language strings and 
expanded the row highlighting.


Dave, what do you think?

Marcus




[1] http://incubator.apache.org/openofficeorg/downloads.html


I'm open for opinions. Otherwise I can put it easily to the
production website as the new "other.html".

Re: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst

[Dave Fisher]

On Aug 26, 2012, at 2:49 PM, Rob Weir wrote:

> On Sun, Aug 26, 2012 at 5:20 PM, Pedro Giffuni  wrote:
>> BTW,
>> 
>> - Original Message -
>> ...
 
 This is already part of the current process. The signatures are in
>>> download_external_dependencies.pl. The Central Maven Repository uses these 
>>> as
>>> well.
 
>>> 
>>> Those are MD5 hashes, not signatures.MD5 has been broken since 1996:
>>> 
>>> http://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities
>>> 
>> 
>> We can simply replace MD5 with SHA256 (Apache-Extras
>> generates SHA1).
>> 
> 
> Good enough for Bitcoins...

r1377529 removes SVN!

I'm checking to see what is Maven central - http://search.maven.org/

Regards,
Dave

> 
>> Pedro.

Re: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst

[Rob Weir]

On Sun, Aug 26, 2012 at 5:20 PM, Pedro Giffuni  wrote:
> BTW,
>
> - Original Message -
> ...
>>>
>>>  This is already part of the current process. The signatures are in
>> download_external_dependencies.pl. The Central Maven Repository uses these as
>> well.
>>>
>>
>> Those are MD5 hashes, not signatures.MD5 has been broken since 1996:
>>
>> http://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities
>>
>
> We can simply replace MD5 with SHA256 (Apache-Extras
> generates SHA1).
>

Good enough for Bitcoins...

> Pedro.

Re: proposed new directory structure for future releases

[Kay Schenk]

On Sun, Aug 26, 2012 at 1:29 PM, Dave Fisher  wrote:

>
> On Aug 26, 2012, at 1:18 PM, Kay Schenk wrote:
>
> > On Sun, Aug 26, 2012 at 10:37 AM, Marcus (OOo) 
> wrote:
> >
> >> Am 08/26/2012 02:26 AM, schrieb Rob Weir:
> >>
> >> On Sat, Aug 25, 2012 at 5:36 PM, Kay Schenk
>  wrote:
> >>>
> 
> 
>  On 08/25/2012 01:28 PM, Andrea Pescetti wrote:
> 
> >
> > On 23/08/2012 22:06, Marcus (OOo) wrote:
> >
> >>
> >> Also IMHO no need to separate between the languages.
> >> Furthermore, when you have to check for a potential error, then you
> you
> >> just need to verify this in a single directory and not more.
> >> /stable/VERSION/
> >>
> >
> >
> > The rest is OK, but removing even the languages subdirectories is
> > probably too much: we already have 20 languages and they could
> > theoretically reach 100+, so it would make sense to preserve the
> > individual subdirectories "en-US", "de", "it" and so on.
> >
> > Regards,
> >Andrea.
> >
> 
> 
>  +1 with Andrea on this one. We should leave the languages in separate
>  directories. And, if folks do "browsing" on SourceForge instead of
> using
>  our
>  download logic, this will make things easier for that purpose as well.
> 
> 
> >>> +1
> >>>
> >>> It also makes it easier if someone wants to burn a CD for just a
> >>> single language.
> >>>
> >>
> >> OK, so our most recent opinion is the following:
> >>
> >> /stable/VERSION//...
> >>
> >> Anyone else with different suggestions?
> >>
> >> Marcus
> >>
> >>
> > I think we were going to drop "stable" and just go with something like
> >
> > /ooo//source
> > /ooo//bin//
> > /ooo//bin/SDK/
> >
> > ...and there was some further discussion on the use of "bin".
> >
> > At any rate, since we only distribute "stable", this is redundant, so we
> > don't need it, and shouldn't have it.
> >
> > Really I like the idea of "bin" to distinguish from source. As long as
> most
> > people continue to download from www.openoffice.org, it is certainly
> not a
> > problem. But, maybe a bit more discussion on this aspect.
>
> s/bin/binaries/
>
>
> /ooo//source
> /ooo//binaries//
> /ooo//binaries/SDK/
>
> Regards,
> Dave
>

yes, that would definitely solve the "bin" double meaning...I thought of
this but I'm happy you suggested it...

OK, can we just go with this new naming scheme, so we can get to work on it?




>
> >
> >
> > --
> >
> 
> > MzK
> >
> > "As a child my family's menu consisted of two choices:
> >take it or leave it. "
> >   -- Buddy Hackett
>
>


-- 

MzK

"As a child my family's menu consisted of two choices:
take it or leave it. "
   -- Buddy Hackett

Re: Unofficial Apache OO Debian repository updated

[Greg Madden]

On Sun, Aug 26, 2012 at 12:47 PM, Wolf Halton  wrote:
> Sounds like it might not take too much effort to get it to work in Ubuntu.
>
> Wolf Halton
> http://sourcefreedom.com
> Apache developer:
> wolfhal...@apache.org
> On Aug 24, 2012 4:37 PM, "Marcelo Santana"  wrote:
>
>> On Sat, 25 Aug 2012 03:45:38 +0800, imacat 
>> wrote:
>>
>> [...]
>>
>> Hi there,
>>
>> > Hmm... in that case, shouldn't these package files work on
>> > Squeeze, too?  Why is Wheezy?  Wheezy is not released yet.
>>
>> I'm not sure, but probably yes because there is no package dependency
>> which prevent it to be installed on the squeeze. But I've not tested
>> yet.

I am a Debian user. I switched to AOO a while back because of a
regression in LO that affects my work. I have been using the dev
builds, works greatthanks.

I am testing Wheezy in a VM , tried the sourceforge Debian repo's. The
issue I am seeing is Debian still uses 'openoffice'  in their package
management systems. Trying to find/install  openoffice results in
links to libreoffice.

While this is probable an issue to discuss with Debian, I am wondering
how this repo is working for others.  What is the package name to
install AOO ?

-- 
Peace

Greg Madden

Re: [DL Website] Prototype of an automatic table with download links

[Marcus (OOo)]

Am 08/26/2012 09:38 PM, schrieb Dave Fisher:


On Aug 26, 2012, at 11:05 AM, Marcus (OOo) wrote:


Hi all,

as promized on Friday I've adjusted the existing automatism to the lastest AOO 
3.4.1 parameters.

The most recent webpage is here:
http://ooo-site.staging.apache.org/download/test/other_print.html


There is one change needed with the source downloads. Please use the Apache 
Mirrors and not dist directly for the packages. See [1].


Only for the source files, not for the hash files, right? Done.


Should the language packs be mixed with the full installation sets? If so then 
maybe the language fields should span two rows?


To have all in a single table it's easier to point the user to resp. the 
user has only to remember this.


I'll think about the span thing.


[1] http://incubator.apache.org/openofficeorg/downloads.html


I'm open for opinions. Otherwise I can put it easily to the production website as the new 
"other.html".


Marcus

Re: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst

[Pedro Giffuni]

BTW,

- Original Message -
...
>> 
>>  This is already part of the current process. The signatures are in 
> download_external_dependencies.pl. The Central Maven Repository uses these as 
> well.
>> 
> 
> Those are MD5 hashes, not signatures.    MD5 has been broken since 1996:
> 
> http://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities
> 

We can simply replace MD5 with SHA256 (Apache-Extras
generates SHA1).

Pedro.

Re: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst

[Dave Fisher]

On Aug 26, 2012, at 1:46 PM, Rob Weir wrote:

> On Sun, Aug 26, 2012 at 3:50 PM, Dave Fisher  wrote:
>> 
>> On Aug 26, 2012, at 12:38 PM, Rob Weir wrote:
>> 
>>> On Sun, Aug 26, 2012 at 3:20 PM, Dave Fisher  wrote:
 Hi,
 
 We need to do more work to have proper compliance with Apache 
 Infrastructure policy in managing external dependencies.
 
 I may not be precisely correct and am looking for confirmation, but In 
 general i think we need to
 
 (1) Completely avoid using svn.apache.org. I don't think we are allowed to 
 do this even as a backup URL.
 
 (2) Use mirrors or maven for ASF dependencies where we use the current 
 release. If we use mirrors then archive.apache.org should be the backup 
 for the mirror so that we aren't in trouble if the project has a release. 
 If a maven repository were used then there would be no issue.
 
 (3) If we use mirrors then we should allow the user to choose which mirror.
 
 If we decide to take the time to go the maven route. I can use the example 
 of ant and maven repos from the Apache POI build.xml.
 
 Notes about maven repos. Infra [1], maven central [2] and example of an 
 externally hosted repo [3]
 
 This area needs careful attention.
 
>> 
>> Please take the time to study the Maven project before you attempt to 
>> reinvent it. [1]
>> 
> 
> I think one could fairly look at the relative creation dates and see
> that Maven reinvented OpenOffice's dependency tracking system ;-)
> 
>>> Note that this move is exactly the wrong thing to do if we want have
>>> buildbots build binaries that are assumed to be safe and therefore
>>> signable.  Instead of the security and verifiability of ASF-run host,
>>> we're putting the dependencies off to a dozen different remote sites,
>>> with no visibility into their site's mechanisms for vetting changes,
>>> access controls, auditability of changes, even basics like ensuring
>>> domain names are renewed and not poached by others.
>>> 
>>> Do we really think other websites are as secure as the ones that Infra
>>> operates?  If so we should move the source code to the other sites as
>>> well, right?
>> 
>> This is not the question. My comments were about using the ASF sites 
>> properly. Joe has told us that we are doing this out of policy.
>> 
> 
> My point is that if we seek to have build-bot automated signed
> binaries it is entirely foreseeable that what we're proposing to do
> with 3rd party dependencies will also be out of policy, due to the
> security concerns.  To do this we'll need to do more than just link to
> random sites on the web for dependencies.

Yes and this is why I brought up Maven.

Here is an example of how our process is fragile if the dependency is another 
Apache project. Every so often there are new release or retirement. When this 
happens the release is moved to the archives.

This problem will happen for one of our dependencies on 12/31/12 when the whole 
Tomcat 5.5.x branch is retired.

With a Maven repository everything goes by an id. I'll research the rules to 
see if it is a solution to all of our dependency issues.

> 
>>> 
>>> No easy resolution of this, but we might mitigate the risk by putting
>>> all of the dependencies to Apache-Extras and load from there
>>> primarily.  And if at all possible make sure all change notifications
>>> from there get echoed to the ooo-committs lis.   We have a better
>>> chance of exercising now screwing up if we control rather than having
>>> multiple 3rd parties control.
>> 
>> We need to differentiate between ASF projects and third party projects. Look 
>> at the current process before you go nuts assuming that everything is 
>> changing.
>> 
> 
> Look at Andre's note from August 3rd.   First locations searched for
> dependencies is the original website where it is hosted.  Then it
> checks Apache Extras.  Then it checks SVN.   Taking SVN out of the
> loop solves one issue.



>  But we still have the other issue -- I think
> Dennis groks this as well -- that our primary search location is less
> secure than the alternatives.

I get it too. apache extras is one easy place for that, but a Maven repository 
may be another. Where and how that gets seeded is our business.

> 
>>> 
>>> Another option would be to use cryptographic means to ensure the
>>> integrity of the remote dependencies, e.g., detached signatures. That
>>> doesn't protect us from another website going down, temporarily or
>>> permanently, but it does allow us to verify that what we are
>>> downloading has not been tampered with.
>> 
>> This is already part of the current process. The signatures are in 
>> download_external_dependencies.pl. The Central Maven Repository uses these 
>> as well.
>> 
> 
> Those are MD5 hashes, not signatures.MD5 has been broken since 1996:
> 
> http://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities
> 
> Again, two relatively simple improvements:
> 
> 1) S

Re: AOO "long-term support" ?

[Rob Weir]

On Sun, Aug 26, 2012 at 3:51 PM, Fernando Cassia  wrote:
> Hi,
>
> I wonder if the ´new management´ at AOO ;) has any plans with regards to
> ´long term support´ for AOO?.
>

We've discussed this topic previously.  You'll read more if you search
the list archives for "LTS".

IMHO the point of LTS is that someone can deploy and expect not to be
surprised by new bugs for a period of time.   They can expect to do
light maintenance, with patches, but the project will try hard to
avoid introducing any incompatibilities for that stream.

One hurdle we have currently is that we require a complete download
and install for revision.  We have no patch or incremental update
mechanism.  So maintenance is not quite what users would expect in an
LTS situation.

I think we need to resolve that issue before we can effectively make
any kind of LTS statements.

-Rob

> supported (bugfixes-stability and security issues if any) for the next ´x´
> years.
>
> Or just how long each version is supported (say, if an AOO 4.0 is released,
> for how long AOO 3.4x will continue having security fixes, etc).
>
> Not that I have any worries or needs on the particular... I was just
> thinking about Ubuntu´s "LTS" releases scheme and the thought crossed my
> mind if AOO project leaders had something like that in mind, or the talk of
> release lifetime was ever thojught or even discussed...
>
> So, I´m all ears. ;)
> FC
>
> --
> During times of Universal Deceit, telling the truth becomes a revolutionary
> act
> - George Orwell

Re: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst

[Pedro Giffuni]

- Original Message -
,,,
>> 
>>  Please take the time to study the Maven project before you attempt to 
> reinvent it. [1]
>> 
> 
> I think one could fairly look at the relative creation dates and see
> that Maven reinvented OpenOffice's dependency tracking system ;-)
> 

Both are reinvention of FreeBSD's ports tree (where checksums have
been working very reliably for both security and consistency). The
question is which is more reliable and flexible.

If we use maven will that involve an extra dependency on Java?

Cheers,

Pedro.

Re: Unofficial Apache OO Debian repository updated

[Wolf Halton]

Sounds like it might not take too much effort to get it to work in Ubuntu.

Wolf Halton
http://sourcefreedom.com
Apache developer:
wolfhal...@apache.org
On Aug 24, 2012 4:37 PM, "Marcelo Santana"  wrote:

> On Sat, 25 Aug 2012 03:45:38 +0800, imacat 
> wrote:
>
> [...]
>
> Hi there,
>
> > Hmm... in that case, shouldn't these package files work on
> > Squeeze, too?  Why is Wheezy?  Wheezy is not released yet.
>
> I'm not sure, but probably yes because there is no package dependency
> which prevent it to be installed on the squeeze. But I've not tested
> yet.
>
>
> Regards,
>
> --
> Marcelo G. Santana (aka msantana) | GNU/Linux User number: #208778
>   http://blog.msantana.eng.br | http://identi.ca/mgsantana
>   http://www.debianbrasil.org | http://br.gnome.org
>  GnuPG fprint: 88FB 5D63 ED02 3B5D 90D6  3A3E 8698 1CC9 89C5 5467
>

Re: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst

[Rob Weir]

On Sun, Aug 26, 2012 at 3:50 PM, Dave Fisher  wrote:
>
> On Aug 26, 2012, at 12:38 PM, Rob Weir wrote:
>
>> On Sun, Aug 26, 2012 at 3:20 PM, Dave Fisher  wrote:
>>> Hi,
>>>
>>> We need to do more work to have proper compliance with Apache 
>>> Infrastructure policy in managing external dependencies.
>>>
>>> I may not be precisely correct and am looking for confirmation, but In 
>>> general i think we need to
>>>
>>> (1) Completely avoid using svn.apache.org. I don't think we are allowed to 
>>> do this even as a backup URL.
>>>
>>> (2) Use mirrors or maven for ASF dependencies where we use the current 
>>> release. If we use mirrors then archive.apache.org should be the backup for 
>>> the mirror so that we aren't in trouble if the project has a release. If a 
>>> maven repository were used then there would be no issue.
>>>
>>> (3) If we use mirrors then we should allow the user to choose which mirror.
>>>
>>> If we decide to take the time to go the maven route. I can use the example 
>>> of ant and maven repos from the Apache POI build.xml.
>>>
>>> Notes about maven repos. Infra [1], maven central [2] and example of an 
>>> externally hosted repo [3]
>>>
>>> This area needs careful attention.
>>>
>
> Please take the time to study the Maven project before you attempt to 
> reinvent it. [1]
>

I think one could fairly look at the relative creation dates and see
that Maven reinvented OpenOffice's dependency tracking system ;-)

>> Note that this move is exactly the wrong thing to do if we want have
>> buildbots build binaries that are assumed to be safe and therefore
>> signable.  Instead of the security and verifiability of ASF-run host,
>> we're putting the dependencies off to a dozen different remote sites,
>> with no visibility into their site's mechanisms for vetting changes,
>> access controls, auditability of changes, even basics like ensuring
>> domain names are renewed and not poached by others.
>>
>> Do we really think other websites are as secure as the ones that Infra
>> operates?  If so we should move the source code to the other sites as
>> well, right?
>
> This is not the question. My comments were about using the ASF sites 
> properly. Joe has told us that we are doing this out of policy.
>

My point is that if we seek to have build-bot automated signed
binaries it is entirely foreseeable that what we're proposing to do
with 3rd party dependencies will also be out of policy, due to the
security concerns.  To do this we'll need to do more than just link to
random sites on the web for dependencies.

>>
>> No easy resolution of this, but we might mitigate the risk by putting
>> all of the dependencies to Apache-Extras and load from there
>> primarily.  And if at all possible make sure all change notifications
>> from there get echoed to the ooo-committs lis.   We have a better
>> chance of exercising now screwing up if we control rather than having
>> multiple 3rd parties control.
>
> We need to differentiate between ASF projects and third party projects. Look 
> at the current process before you go nuts assuming that everything is 
> changing.
>

Look at Andre's note from August 3rd.   First locations searched for
dependencies is the original website where it is hosted.  Then it
checks Apache Extras.  Then it checks SVN.   Taking SVN out of the
loop solves one issue.  But we still have the other issue -- I think
Dennis groks this as well -- that our primary search location is less
secure than the alternatives.

>>
>> Another option would be to use cryptographic means to ensure the
>> integrity of the remote dependencies, e.g., detached signatures. That
>> doesn't protect us from another website going down, temporarily or
>> permanently, but it does allow us to verify that what we are
>> downloading has not been tampered with.
>
> This is already part of the current process. The signatures are in 
> download_external_dependencies.pl. The Central Maven Repository uses these as 
> well.
>

Those are MD5 hashes, not signatures.MD5 has been broken since 1996:

http://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities

Again, two relatively simple improvements:

1) Search Apache Extras first

or

2) Have the current script verify a detached signature rather than
relying on MD5 hashes


Note:  the MD5 hashes were OK previously, since we also maintained
control over the actually files.  This was true under Sun/Oracle, as
well as earlier in the Podling.   But the risk profile changes
significantly once we start retrieving these files from a website over
which we have no control.

-Rob



> [1] http://maven.apache.org/
>
>>
>
>
>>
>> -Rob
>>
>>
>>> The current script is here: 
>>> main/solenv/bin/download_external_dependencies.pl
>>>
>>> Regards,
>>> Dave
>>>
>>> [1] http://apache.org/dev/repository-faq.html  and
>>> [2] http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>> [3] 
>>> http://repo.maven.apache.org/maven2/javax/activation/activation/1.0.2/activation-1.0.2.pom
>>>

Re: Open-office downloading site - FLV player advertisement

[Dave Fisher]

Hi Jonas,

We've been looking into to your issue and Roberto has a question for you. See 
the bottom.

(Sorry, but not everyone notices when a question has been moderated into the 
list.)

On Aug 26, 2012, at 1:19 PM, Roberto Galoppini wrote:

> On Sun, Aug 26, 2012 at 10:05 PM, Fernando Cassia  wrote:
> 
>> On Sun, Aug 26, 2012 at 4:48 PM, Roberto Galoppini >> wrote:
>> 
>>> Hi Jonas,
>>> 
>>> if you run in a similar problem please advise me about the exact URL, we
>>> need that to prevent it to happen again in the future.
>>> 
>>> Thanks,
>>> 
>> 
>> 
>> See the attached screenshot. The ads are part of the SF.net third party
>> adverts, but these advertisers put a green "download" button on their
>> banners... of course the adverts are for other ´products´ but as these ads
>> are shown while the user is waiting for the download to start, the intent
>> is evident... many users will blindly click anything that says
>> ´download´...
>> 
>> http://img109.imageshack.us/img109/9490/sfadsgreendownloadbutto.png
>> 
>> hope this helps
>> FC
>> 
> 
> Thanks Fernando,
> 
> actually in different geographies are displayed different ads, and I need
> the actual URL to eventually report internally issues with malware. Can you
> help me with that?

Regards,
Dave



> 
> Roberto
> 
> 
>> 
>>> 
>>> Roberto
>>> 
>> 
>> 
>> 
>> --
>> During times of Universal Deceit, telling the truth becomes a revolutionary
>> act
>> Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto
>> Revolucionario
>> - George Orwell
>> 
> 
> -- 
> 
> This e- mail message is intended only for the named recipient(s) above. It 
> may contain confidential and privileged information. If you are not the 
> intended recipient you are hereby notified that any dissemination, 
> distribution or copying of this e-mail and any attachment(s) is strictly 
> prohibited. If you have received this e-mail in error, please immediately 
> notify the sender by replying to this e-mail and delete the message and any 
> attachment(s) from your system. Thank you.
> 

Re: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst

[Rob Weir]

n Sun, Aug 26, 2012 at 3:54 PM, Pedro Giffuni  wrote:
>
>
> - Original Message -
>
>>
>> On Sun, Aug 26, 2012 at 3:20 PM, Dave Fisher 
>> wrote:
>>>  Hi,
>>>
>>>  We need to do more work to have proper compliance with Apache
>> Infrastructure policy in managing external dependencies.
>>>
>>>  I may not be precisely correct and am looking for confirmation, but In
>> general i think we need to
>>>
>>>  (1) Completely avoid using svn.apache.org. I don't think we are allowed
>> to do this even as a backup URL.
>>>
>>>  (2) Use mirrors or maven for ASF dependencies where we use the current
>> release. If we use mirrors then archive.apache.org should be the backup for 
>> the
>> mirror so that we aren't in trouble if the project has a release. If a maven
>> repository were used then there would be no issue.
>>>
>>>  (3) If we use mirrors then we should allow the user to choose which mirror.
>>>
>>>  If we decide to take the time to go the maven route. I can use the example
>> of ant and maven repos from the Apache POI build.xml.
>>>
>>>  Notes about maven repos. Infra [1], maven central [2] and example of an
>> externally hosted repo [3]
>>>
>>>  This area needs careful attention.
>>>
>>
>> Note that this move is exactly the wrong thing to do if we want have
>> buildbots build binaries that are assumed to be safe and therefore
>> signable.  Instead of the security and verifiability of ASF-run host,
>> we're putting the dependencies off to a dozen different remote sites,
>> with no visibility into their site's mechanisms for vetting changes,
>> access controls, auditability of changes, even basics like ensuring
>> domain names are renewed and not poached by others.
>>
>
> This is not true. We use checksums precisely to certify the source tarballs
> haven't been tampered with.
>

If we think that then we're fooling ourselves.  Checksums are
effective for detecting accidental corruption during transmission, or
for detecting when someone casually modifies a file.  It does very
little to prevent us against malicious changes.  To be specific:  One
can make whatever changes one wishes in a file to insert malicious
code, and then via brute force (or better) make other changes to an
unrelated file in the archive in order to achieve the desired hash
collision.  Is it computationally expensive?  Yes.  Is it impossible?
No.  Does a binary used by 10 million people present an incentive that
would attract that kind of attention?  I don't want to find out.

This is why Apache releases have the detached digital signature as
well.  It gives a much higher degree of safety.

>
>
>> Do we really think other websites are as secure as the ones that Infra
>> operates?  If so we should move the source code to the other sites as
>> well, right?
>>
>
> Yes, upstream providers generate checksums and do proper
> maintainance of their packages but perhaps more importantly by
> working with them we can leverage their mirrors more efficiently.
>
> I agree with Dave; we have to get rid of those tarballs
> in SVN. Python 2.6.1 will be axed today, BTW.
>
>  I haven't looked at Maven but it sounds like something
> we should look at..
>
> Pedro.

Re: proposed new directory structure for future releases

[Dave Fisher]

On Aug 26, 2012, at 1:18 PM, Kay Schenk wrote:

> On Sun, Aug 26, 2012 at 10:37 AM, Marcus (OOo)  wrote:
> 
>> Am 08/26/2012 02:26 AM, schrieb Rob Weir:
>> 
>> On Sat, Aug 25, 2012 at 5:36 PM, Kay Schenk  wrote:
>>> 
 
 
 On 08/25/2012 01:28 PM, Andrea Pescetti wrote:
 
> 
> On 23/08/2012 22:06, Marcus (OOo) wrote:
> 
>> 
>> Also IMHO no need to separate between the languages.
>> Furthermore, when you have to check for a potential error, then you you
>> just need to verify this in a single directory and not more.
>> /stable/VERSION/
>> 
> 
> 
> The rest is OK, but removing even the languages subdirectories is
> probably too much: we already have 20 languages and they could
> theoretically reach 100+, so it would make sense to preserve the
> individual subdirectories "en-US", "de", "it" and so on.
> 
> Regards,
>Andrea.
> 
 
 
 +1 with Andrea on this one. We should leave the languages in separate
 directories. And, if folks do "browsing" on SourceForge instead of using
 our
 download logic, this will make things easier for that purpose as well.
 
 
>>> +1
>>> 
>>> It also makes it easier if someone wants to burn a CD for just a
>>> single language.
>>> 
>> 
>> OK, so our most recent opinion is the following:
>> 
>> /stable/VERSION//...
>> 
>> Anyone else with different suggestions?
>> 
>> Marcus
>> 
>> 
> I think we were going to drop "stable" and just go with something like
> 
> /ooo//source
> /ooo//bin//
> /ooo//bin/SDK/
> 
> ...and there was some further discussion on the use of "bin".
> 
> At any rate, since we only distribute "stable", this is redundant, so we
> don't need it, and shouldn't have it.
> 
> Really I like the idea of "bin" to distinguish from source. As long as most
> people continue to download from www.openoffice.org, it is certainly not a
> problem. But, maybe a bit more discussion on this aspect.

s/bin/binaries/


/ooo//source
/ooo//binaries//
/ooo//binaries/SDK/

Regards,
Dave

> 
> 
> -- 
> 
> MzK
> 
> "As a child my family's menu consisted of two choices:
>take it or leave it. "
>   -- Buddy Hackett

Re: [DISCUSS][Linux]Drop distro specific RPMs

[Kay Schenk]

On Sun, Aug 26, 2012 at 9:34 AM, RGB ES  wrote:

> 2012/8/26 Kay Schenk :
> > On Sun, Aug 26, 2012 at 5:13 AM, RGB ES  wrote:
> >
> >> This time I installed not the "suse" desktop integration RPM but the
> >> "freedesktop" one, and it worked without problems. If someone confirm
> >> that this is the same for fedora and mandriva then I think we can
> >> safely drop those distro specific RPMs and offer only one, like we
> >> offer only one .deb on the debian packages.
> >>
> >> What do you think?
> >>
> >> Regards
> >> Ricardo
> >>
> >
> > This is interesting. I should try this one as well and see what happens.
> >
> > Can you provide further details?
> >
> > What distro are you using? What window manager are you using, etc.
> >
>
> openSUSE 11.4, 64 bits, with KDE SC 4.8.4. On a couple of weeks maybe
> I'll try with openSUSE 12.2.
>
> The freedesktop package provided the menu entries, the mime type
> icons... and I can use krunner to launch any AOO app.
>
> Regards
> Ricardo
>

OK, thanks. I should install this someplace and see that the file structure
is.

-- 

MzK

"As a child my family's menu consisted of two choices:
take it or leave it. "
   -- Buddy Hackett

Re: [Realease Notes] Proposed template for creation o Release Notes

[Kay Schenk]

On Sat, Aug 25, 2012 at 10:32 AM, Keith N. McKenna <
keith.mcke...@comcast.net> wrote:

> Kay Schenk wrote:
>
>> On Fri, Aug 24, 2012 at 4:32 PM, Keith N. McKenna <
>> keith.mcke...@comcast.net
>>
>>> wrote:
>>>
>>
>>  Kay Schenk wrote:
>>>
>>>  On Fri, Aug 24, 2012 at 10:43 AM, Keith N. McKenna <
 keith.mcke...@comcast.net> wrote:

   Hello All;

>
> I have a proposed draft of a template for use in creating Release
> Notes
> at: 
> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
> **
> **>
> Release+Notes+Templatehttp://cwiki.apache.org/confluence/**>
> display/OOOUSERS/Release+Notes+Template apache.org/confluence/display/**OOOUSERS/Release+Notes+**Template
> >
>
>  .
>>
>
> All comments and changes are welcome. I believe that there is a way to
> generate actual templates for the Confluence wiki and I will be digging
> through the documentation for it to try and figure out how to do so.
>
> Regards
> Keith
>
>
>   Looks good to me. I think using a template like this will be good for
>
 organization.


   Thanks Kay, that was one of the ideas that prompted me to do this. I

>>> noted that you said in an earlier thread that converting the notes from
>>> the
>>> wiki to HTML took some futzing. Are we using the HTML export add-on
>>> that is available or Conluence or are you doing it by hand?
>>>
>>> Regards
>>> Keith
>>>
>>>
>> I use the html export but it puts it some styling that we don't use on the
>> web site and it needs to be removed. I'll need to see how it looks if we
>> just left this in. And then, maybe no futzing needed. Or, maybe I'm doing
>> something wrong. :/ I'll do this again at some point.
>>
>>
>>
>>
>>  I had noticed the html export when I was rooting through the
> documentation and wasn't sure i it was installed on our instance of
> Confluence. Figured that it couldn't hurt to ask. My background is in
> manufacturing engineering and I am a very large fan of making sure that
> there are more efficient ways of accomplishing redundant  and potentially
> error prone tasks.
>

well, it's a curious thing. I DO the html export but for some reason
although the file IS an html file, it makes into ".doc". I need to check
some of what I told you about this by the way.  At any rate, the html
export is there.


>
> Your knowledge of web design and support shows in the quality of your
> work. On the other hand what I know of the subject and HTML in general
> would it on the head of a pin and have room left for thousands of angels.
> :oD.
>

Thank you, but I'm not sure  I deserve the extent of this complement.  I
had little to do with the COMPLETE design of www.openoffice.org. I do know
a LOT about  bare bones html though. CSS, maybe not so much, but enough to
get by  most of the time. :)



-- 

MzK

"As a child my family's menu consisted of two choices:
take it or leave it. "
   -- Buddy Hackett

Re: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst

[Dave Fisher]

On Aug 26, 2012, at 1:08 PM, Dennis E. Hamilton wrote:

> I haven't said anything about modifications to an upstream source.  That's an 
> entirely different problem.

Yes. I think that is what concerns Rob. Maintenance of necessary forks and 
protection from lost dependencies.

> 
> I'm talking about dependencies on someone else's binaries of any kind. 

We need to be concerned about required binary dependencies. We should 
definitely keep copies of these, and build from our copies.

Regards,
Dave

> 
> - Dennis
> 
> PS: In my own analysis, I probably should have mentioned bundled extensions 
> too, although that seems to be a rather AOO-specific case.  At some point, 
> the entire extension provenance and authenticity case *will* come under 
> scrutiny.
> 
> -Original Message-
> From: Dave Fisher [mailto:dave2w...@comcast.net] 
> Sent: Sunday, August 26, 2012 12:57
> To: ooo-dev@incubator.apache.org
> Subject: Re: svn commit: r1377482 - 
> /incubator/ooo/trunk/main/external_deps.lst
> 
> 
> On Aug 26, 2012, at 12:47 PM, Dennis E. Hamilton wrote:
> 
>> +1 on preserving the provenance and integrity of binary dependencies.
>> 
>> I'd go with external signatures *and* hosting the specific artifacts on a 
>> reliable ASF location for preservation along with all ASF project sources 
>> that depended on those specific artifacts in any sort of review, release of 
>> authenticated binaries, etc.
> 
> There is nothing to say that we can't make our modifications with code from 
> svn and base code stored in a reliable location. We can then push this to 
> either extras and/or maven central.
> 
> Regards,
> Dave
> 
>> 
>> - Dennis
>> 
>> -Original Message-
>> From: Rob Weir [mailto:robw...@apache.org] 
>> Sent: Sunday, August 26, 2012 12:38
>> To: ooo-dev@incubator.apache.org
>> Subject: Re: svn commit: r1377482 - 
>> /incubator/ooo/trunk/main/external_deps.lst
>> 
>> On Sun, Aug 26, 2012 at 3:20 PM, Dave Fisher  wrote:
>>> Hi,
>>> 
>>> We need to do more work to have proper compliance with Apache 
>>> Infrastructure policy in managing external dependencies.
>>> 
>>> I may not be precisely correct and am looking for confirmation, but In 
>>> general i think we need to
>>> 
>>> (1) Completely avoid using svn.apache.org. I don't think we are allowed to 
>>> do this even as a backup URL.
>>> 
>>> (2) Use mirrors or maven for ASF dependencies where we use the current 
>>> release. If we use mirrors then archive.apache.org should be the backup for 
>>> the mirror so that we aren't in trouble if the project has a release. If a 
>>> maven repository were used then there would be no issue.
>>> 
>>> (3) If we use mirrors then we should allow the user to choose which mirror.
>>> 
>>> If we decide to take the time to go the maven route. I can use the example 
>>> of ant and maven repos from the Apache POI build.xml.
>>> 
>>> Notes about maven repos. Infra [1], maven central [2] and example of an 
>>> externally hosted repo [3]
>>> 
>>> This area needs careful attention.
>>> 
>> 
>> Note that this move is exactly the wrong thing to do if we want have
>> buildbots build binaries that are assumed to be safe and therefore
>> signable.  Instead of the security and verifiability of ASF-run host,
>> we're putting the dependencies off to a dozen different remote sites,
>> with no visibility into their site's mechanisms for vetting changes,
>> access controls, auditability of changes, even basics like ensuring
>> domain names are renewed and not poached by others.
>> 
>> Do we really think other websites are as secure as the ones that Infra
>> operates?  If so we should move the source code to the other sites as
>> well, right?
>> 
>> No easy resolution of this, but we might mitigate the risk by putting
>> all of the dependencies to Apache-Extras and load from there
>> primarily.  And if at all possible make sure all change notifications
>> from there get echoed to the ooo-committs lis.   We have a better
>> chance of exercising now screwing up if we control rather than having
>> multiple 3rd parties control.
>> 
>> Another option would be to use cryptographic means to ensure the
>> integrity of the remote dependencies, e.g., detached signatures. That
>> doesn't protect us from another website going down, temporarily or
>> permanently, but it does allow us to verify that what we are
>> downloading has not been tampered with.
>> 
>> -Rob
>> 
>> 
>>> The current script is here: 
>>> main/solenv/bin/download_external_dependencies.pl
>>> 
>>> Regards,
>>> Dave
>>> 
>>> [1] http://apache.org/dev/repository-faq.html  and
>>> [2] http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>>> [3] 
>>> http://repo.maven.apache.org/maven2/javax/activation/activation/1.0.2/activation-1.0.2.pom
>>> 
>>> 
>>> On Aug 26, 2012, at 11:58 AM, w...@apache.org wrote:
>>> 
 Author: wave
 Date: Sun Aug 26 18:58:08 2012
 New Revision: 1377482
 
 URL: http://svn.apache.org/viewvc?rev=1377482&view=rev
 Lo

Re: Open-office downloading site - FLV player advertisement

[Roberto Galoppini]

On Sun, Aug 26, 2012 at 10:05 PM, Fernando Cassia  wrote:

> On Sun, Aug 26, 2012 at 4:48 PM, Roberto Galoppini  >wrote:
>
> > Hi Jonas,
> >
> >  if you run in a similar problem please advise me about the exact URL, we
> > need that to prevent it to happen again in the future.
> >
> > Thanks,
> >
>
>
> See the attached screenshot. The ads are part of the SF.net third party
> adverts, but these advertisers put a green "download" button on their
> banners... of course the adverts are for other ´products´ but as these ads
> are shown while the user is waiting for the download to start, the intent
> is evident... many users will blindly click anything that says
> ´download´...
>
> http://img109.imageshack.us/img109/9490/sfadsgreendownloadbutto.png
>
> hope this helps
> FC
>

Thanks Fernando,

 actually in different geographies are displayed different ads, and I need
the actual URL to eventually report internally issues with malware. Can you
help me with that?

Roberto


>
> >
> > Roberto
> >
>
>
>
> --
> During times of Universal Deceit, telling the truth becomes a revolutionary
> act
> Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto
> Revolucionario
> - George Orwell
>

-- 

This e- mail message is intended only for the named recipient(s) above. It 
may contain confidential and privileged information. If you are not the 
intended recipient you are hereby notified that any dissemination, 
distribution or copying of this e-mail and any attachment(s) is strictly 
prohibited. If you have received this e-mail in error, please immediately 
notify the sender by replying to this e-mail and delete the message and any 
attachment(s) from your system. Thank you.

Re: proposed new directory structure for future releases

[Kay Schenk]

On Sun, Aug 26, 2012 at 10:37 AM, Marcus (OOo)  wrote:

> Am 08/26/2012 02:26 AM, schrieb Rob Weir:
>
>  On Sat, Aug 25, 2012 at 5:36 PM, Kay Schenk  wrote:
>>
>>>
>>>
>>> On 08/25/2012 01:28 PM, Andrea Pescetti wrote:
>>>

 On 23/08/2012 22:06, Marcus (OOo) wrote:

>
> Also IMHO no need to separate between the languages.
> Furthermore, when you have to check for a potential error, then you you
> just need to verify this in a single directory and not more.
> /stable/VERSION/
>


 The rest is OK, but removing even the languages subdirectories is
 probably too much: we already have 20 languages and they could
 theoretically reach 100+, so it would make sense to preserve the
 individual subdirectories "en-US", "de", "it" and so on.

 Regards,
 Andrea.

>>>
>>>
>>> +1 with Andrea on this one. We should leave the languages in separate
>>> directories. And, if folks do "browsing" on SourceForge instead of using
>>> our
>>> download logic, this will make things easier for that purpose as well.
>>>
>>>
>> +1
>>
>> It also makes it easier if someone wants to burn a CD for just a
>> single language.
>>
>
> OK, so our most recent opinion is the following:
>
> /stable/VERSION//...
>
> Anyone else with different suggestions?
>
> Marcus
>
>
I think we were going to drop "stable" and just go with something like

/ooo//source
/ooo//bin//
/ooo//bin/SDK/

...and there was some further discussion on the use of "bin".

At any rate, since we only distribute "stable", this is redundant, so we
don't need it, and shouldn't have it.

Really I like the idea of "bin" to distinguish from source. As long as most
people continue to download from www.openoffice.org, it is certainly not a
problem. But, maybe a bit more discussion on this aspect.


-- 

MzK

"As a child my family's menu consisted of two choices:
take it or leave it. "
   -- Buddy Hackett

RE: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst

[Dennis E. Hamilton]

I haven't said anything about modifications to an upstream source.  That's an 
entirely different problem.

I'm talking about dependencies on someone else's binaries of any kind. 

 - Dennis

PS: In my own analysis, I probably should have mentioned bundled extensions 
too, although that seems to be a rather AOO-specific case.  At some point, the 
entire extension provenance and authenticity case *will* come under scrutiny.

-Original Message-
From: Dave Fisher [mailto:dave2w...@comcast.net] 
Sent: Sunday, August 26, 2012 12:57
To: ooo-dev@incubator.apache.org
Subject: Re: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst


On Aug 26, 2012, at 12:47 PM, Dennis E. Hamilton wrote:

> +1 on preserving the provenance and integrity of binary dependencies.
> 
> I'd go with external signatures *and* hosting the specific artifacts on a 
> reliable ASF location for preservation along with all ASF project sources 
> that depended on those specific artifacts in any sort of review, release of 
> authenticated binaries, etc.

There is nothing to say that we can't make our modifications with code from svn 
and base code stored in a reliable location. We can then push this to either 
extras and/or maven central.

Regards,
Dave

> 
> - Dennis
> 
> -Original Message-
> From: Rob Weir [mailto:robw...@apache.org] 
> Sent: Sunday, August 26, 2012 12:38
> To: ooo-dev@incubator.apache.org
> Subject: Re: svn commit: r1377482 - 
> /incubator/ooo/trunk/main/external_deps.lst
> 
> On Sun, Aug 26, 2012 at 3:20 PM, Dave Fisher  wrote:
>> Hi,
>> 
>> We need to do more work to have proper compliance with Apache Infrastructure 
>> policy in managing external dependencies.
>> 
>> I may not be precisely correct and am looking for confirmation, but In 
>> general i think we need to
>> 
>> (1) Completely avoid using svn.apache.org. I don't think we are allowed to 
>> do this even as a backup URL.
>> 
>> (2) Use mirrors or maven for ASF dependencies where we use the current 
>> release. If we use mirrors then archive.apache.org should be the backup for 
>> the mirror so that we aren't in trouble if the project has a release. If a 
>> maven repository were used then there would be no issue.
>> 
>> (3) If we use mirrors then we should allow the user to choose which mirror.
>> 
>> If we decide to take the time to go the maven route. I can use the example 
>> of ant and maven repos from the Apache POI build.xml.
>> 
>> Notes about maven repos. Infra [1], maven central [2] and example of an 
>> externally hosted repo [3]
>> 
>> This area needs careful attention.
>> 
> 
> Note that this move is exactly the wrong thing to do if we want have
> buildbots build binaries that are assumed to be safe and therefore
> signable.  Instead of the security and verifiability of ASF-run host,
> we're putting the dependencies off to a dozen different remote sites,
> with no visibility into their site's mechanisms for vetting changes,
> access controls, auditability of changes, even basics like ensuring
> domain names are renewed and not poached by others.
> 
> Do we really think other websites are as secure as the ones that Infra
> operates?  If so we should move the source code to the other sites as
> well, right?
> 
> No easy resolution of this, but we might mitigate the risk by putting
> all of the dependencies to Apache-Extras and load from there
> primarily.  And if at all possible make sure all change notifications
> from there get echoed to the ooo-committs lis.   We have a better
> chance of exercising now screwing up if we control rather than having
> multiple 3rd parties control.
> 
> Another option would be to use cryptographic means to ensure the
> integrity of the remote dependencies, e.g., detached signatures. That
> doesn't protect us from another website going down, temporarily or
> permanently, but it does allow us to verify that what we are
> downloading has not been tampered with.
> 
> -Rob
> 
> 
>> The current script is here: main/solenv/bin/download_external_dependencies.pl
>> 
>> Regards,
>> Dave
>> 
>> [1] http://apache.org/dev/repository-faq.html  and
>> [2] http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>> [3] 
>> http://repo.maven.apache.org/maven2/javax/activation/activation/1.0.2/activation-1.0.2.pom
>> 
>> 
>> On Aug 26, 2012, at 11:58 AM, w...@apache.org wrote:
>> 
>>> Author: wave
>>> Date: Sun Aug 26 18:58:08 2012
>>> New Revision: 1377482
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1377482&view=rev
>>> Log:
>>> one more small step to infra compliance. still to do removing use of svn as 
>>> a backup and for current releases of ASF software the archive is not proper 
>>> - either a mirror or the maven repository is required.
>>> 
>>> Modified:
>>>   incubator/ooo/trunk/main/external_deps.lst
>>> 
>>> Modified: incubator/ooo/trunk/main/external_deps.lst
>>> URL: 
>>> http://svn.apache.org/viewvc/incubator/ooo/trunk/main/external_deps.lst?rev=1377482&r1=1377481&r2=1377482&v

Re: Open-office downloading site - FLV player advertisement

[Fernando Cassia]

On Sun, Aug 26, 2012 at 4:48 PM, Roberto Galoppini wrote:

> Hi Jonas,
>
>  if you run in a similar problem please advise me about the exact URL, we
> need that to prevent it to happen again in the future.
>
> Thanks,
>


See the attached screenshot. The ads are part of the SF.net third party
adverts, but these advertisers put a green "download" button on their
banners... of course the adverts are for other ´products´ but as these ads
are shown while the user is waiting for the download to start, the intent
is evident... many users will blindly click anything that says ´download´...

http://img109.imageshack.us/img109/9490/sfadsgreendownloadbutto.png

hope this helps
FC

>
> Roberto
>



-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto
Revolucionario
- George Orwell

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Dave Fisher]

On Aug 26, 2012, at 12:54 PM, Dave Fisher wrote:

> 
> On Aug 26, 2012, at 12:42 PM, Dennis E. Hamilton wrote:
> 
>> FYI, concerning the matter of binaries distributed by the Apache OpenOffice 
>> project.
>> 
>> I neglected to consider a case that Dave Fisher just raised here on ooo-dev: 
>> Where the binary dependencies relied upon in an Apache OpenOffice binary 
>> distribution are accessed from at build time and where those are 
>> identifiably preserved for purposes of replication/confirmation and also for 
>> any future forensic need.  That is an element in my topic (2) below.
> 
> Before we all light our hair on fire. I'm only saying that the build must not 
> pull these out of svn, even as a backup. If you examine the current scripts 
> that has been done already.

Correction - the scripts go to external sources first. I am prosing to take 
away the svn fallback.

> 
> Regards,
> Dave
> 
>> 
>> Please do not comment on the general@ i.a.o thread.  It is a zombie in the 
>> process of being burned at the stake.
>> 
>> - Dennis
>> 
>> -Original Message-
>> From: Dennis E. Hamilton [mailto:orc...@apache.org] 
>> Sent: Sunday, August 26, 2012 12:12
>> To: gene...@incubator.apache.org
>> Subject: RE: [VOTE] Apache OpenOffice Community Graduation Vote
>> 
>> Since my post was mentioned later on this thread, I thought I would 
>> summarize what I have as the take-away from intervening discussion.  I have 
>> no intention to deal with the use of language (i.e., semantics of 
>> "convenience") and the way that tacit policy understanding is conveyed among 
>> Apache project participants.
>> 
>> I will also refrain from any further additions to this topic.
>> 
>> TAKE-AWAYS
>> 
>> With regard to the production and delivery to users of authentic Apache 
>> OpenOffice binary builds, there seem to be the following concerns 
>> (especially for, but not limited to, Windows and Apple binaries and 
>> aggravated further by the restraints that are growing around evolving "App 
>> Store" requirements for consumer- and cloud-oriented platforms).  I see 
>> three cases:
>> 
>>  1. Authentication of binaries
>>  2. Provenance of bundled binary dependencies 
>>  3. Availability of source for inspection, audit, and provenance
>> 
>> 1. AUTHENTICATION OF BINARIES
>> 
>> The desire for binaries to be signed using digital signatures with private 
>> keys held by the ASF is a natural concern for authentication of a variety of 
>> binaries produced by Apache projects.
>> 
>> There appears to be agreement that any such signature introductions must be 
>> done by ASF-authorized agents.  The conclusion is that infrastructure would 
>> perform such signings.  These signings, by virtue of their modification of 
>> the unsigned binary, will invalidate any external signatures that were 
>> prepared as part of the release process.  (It is possible to extract the 
>> internal signature and verify an external signature, if that is ever any 
>> question about that.)
>> 
>> The signing party would have the reliance of the release-manager external 
>> signatures and other attestation that the binary is produced from the 
>> release sources.
>> 
>> This still leaves open additional concerns about the conditions under which 
>> the binaries are produced and any difficulties that result.
>> 
>> An alternative is for the signing authority to also produce the binaries, 
>> using the release sources directly on secured build machines.  There are a 
>> number of technical problems that arise in this case, unless the release 
>> candidates were built in the same manner but not (yet) signed.  That could 
>> work.  It would also confirm that the binaries are indeed produced from the 
>> release's sources using the parameters for the platform presumably also 
>> included in the source materials.
>> 
>> The remaining question is, what is being attested to by the production of 
>> binaries that are authenticated in this manner? Simply that they have been 
>> built in this manner and that it was done using ASF infrastructure, the 
>> integrity of which the ASF can be accountable for.  It is not an attestation 
>> that there are no bugs, no security defects, or even that the IP provenance 
>> is assured to be clean.  It is that the binary was produced under these 
>> particular verifiable conditions from the source materials provided as part 
>> of the source release along with dependencies on binaries incorporated in 
>> the build.  
>> 
>> It also provides a strong differentiator for binaries, however they might be 
>> identified, including even release candidates and developer builds, that 
>> were not provided in this manner.
>> 
>> 2. PROVENANCE OF BUNDLED BINARY DEPENDENCIES
>> 
>> A complication in (1) is the incorporation of binary resources on which the 
>> source-code release depends in order to be built.  These might be authorized 
>> (and usually authenticated) redistributables having closed-source origins.  
>> These might be authoriz

Re: AOO "long-term support" ?

[Dave Fisher]

This is an excellent question. I can only say that other projects at Apache do 
this - on example is Apache Tomcat. Tomcat currently supports three releases:

- 5.5.x which is EOL December of this year. [1]
- 6.0.x
- 7.0.x

Since Tomcat 5.5.x is a dependency of AOO 3.4.x we need to be aware of this in 
our dependency discussion.

Regards,
Dave

[1] http://tomcat.apache.org/tomcat-55-eol.html



On Aug 26, 2012, at 12:51 PM, Fernando Cassia wrote:

> Hi,
> 
> I wonder if the ´new management´ at AOO ;) has any plans with regards to
> ´long term support´ for AOO?.
> 
> I mean... it´d be nice if we knew in advance that AOO 3.4.x will be
> supported (bugfixes-stability and security issues if any) for the next ´x´
> years.
> 
> Or just how long each version is supported (say, if an AOO 4.0 is released,
> for how long AOO 3.4x will continue having security fixes, etc).
> 
> Not that I have any worries or needs on the particular... I was just
> thinking about Ubuntu´s "LTS" releases scheme and the thought crossed my
> mind if AOO project leaders had something like that in mind, or the talk of
> release lifetime was ever thojught or even discussed...
> 
> So, I´m all ears. ;)
> FC
> 
> -- 
> During times of Universal Deceit, telling the truth becomes a revolutionary
> act
> - George Orwell

Re: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst

[Dave Fisher]

On Aug 26, 2012, at 12:47 PM, Dennis E. Hamilton wrote:

> +1 on preserving the provenance and integrity of binary dependencies.
> 
> I'd go with external signatures *and* hosting the specific artifacts on a 
> reliable ASF location for preservation along with all ASF project sources 
> that depended on those specific artifacts in any sort of review, release of 
> authenticated binaries, etc.

There is nothing to say that we can't make our modifications with code from svn 
and base code stored in a reliable location. We can then push this to either 
extras and/or maven central.

Regards,
Dave

> 
> - Dennis
> 
> -Original Message-
> From: Rob Weir [mailto:robw...@apache.org] 
> Sent: Sunday, August 26, 2012 12:38
> To: ooo-dev@incubator.apache.org
> Subject: Re: svn commit: r1377482 - 
> /incubator/ooo/trunk/main/external_deps.lst
> 
> On Sun, Aug 26, 2012 at 3:20 PM, Dave Fisher  wrote:
>> Hi,
>> 
>> We need to do more work to have proper compliance with Apache Infrastructure 
>> policy in managing external dependencies.
>> 
>> I may not be precisely correct and am looking for confirmation, but In 
>> general i think we need to
>> 
>> (1) Completely avoid using svn.apache.org. I don't think we are allowed to 
>> do this even as a backup URL.
>> 
>> (2) Use mirrors or maven for ASF dependencies where we use the current 
>> release. If we use mirrors then archive.apache.org should be the backup for 
>> the mirror so that we aren't in trouble if the project has a release. If a 
>> maven repository were used then there would be no issue.
>> 
>> (3) If we use mirrors then we should allow the user to choose which mirror.
>> 
>> If we decide to take the time to go the maven route. I can use the example 
>> of ant and maven repos from the Apache POI build.xml.
>> 
>> Notes about maven repos. Infra [1], maven central [2] and example of an 
>> externally hosted repo [3]
>> 
>> This area needs careful attention.
>> 
> 
> Note that this move is exactly the wrong thing to do if we want have
> buildbots build binaries that are assumed to be safe and therefore
> signable.  Instead of the security and verifiability of ASF-run host,
> we're putting the dependencies off to a dozen different remote sites,
> with no visibility into their site's mechanisms for vetting changes,
> access controls, auditability of changes, even basics like ensuring
> domain names are renewed and not poached by others.
> 
> Do we really think other websites are as secure as the ones that Infra
> operates?  If so we should move the source code to the other sites as
> well, right?
> 
> No easy resolution of this, but we might mitigate the risk by putting
> all of the dependencies to Apache-Extras and load from there
> primarily.  And if at all possible make sure all change notifications
> from there get echoed to the ooo-committs lis.   We have a better
> chance of exercising now screwing up if we control rather than having
> multiple 3rd parties control.
> 
> Another option would be to use cryptographic means to ensure the
> integrity of the remote dependencies, e.g., detached signatures. That
> doesn't protect us from another website going down, temporarily or
> permanently, but it does allow us to verify that what we are
> downloading has not been tampered with.
> 
> -Rob
> 
> 
>> The current script is here: main/solenv/bin/download_external_dependencies.pl
>> 
>> Regards,
>> Dave
>> 
>> [1] http://apache.org/dev/repository-faq.html  and
>> [2] http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>> [3] 
>> http://repo.maven.apache.org/maven2/javax/activation/activation/1.0.2/activation-1.0.2.pom
>> 
>> 
>> On Aug 26, 2012, at 11:58 AM, w...@apache.org wrote:
>> 
>>> Author: wave
>>> Date: Sun Aug 26 18:58:08 2012
>>> New Revision: 1377482
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1377482&view=rev
>>> Log:
>>> one more small step to infra compliance. still to do removing use of svn as 
>>> a backup and for current releases of ASF software the archive is not proper 
>>> - either a mirror or the maven repository is required.
>>> 
>>> Modified:
>>>   incubator/ooo/trunk/main/external_deps.lst
>>> 
>>> Modified: incubator/ooo/trunk/main/external_deps.lst
>>> URL: 
>>> http://svn.apache.org/viewvc/incubator/ooo/trunk/main/external_deps.lst?rev=1377482&r1=1377481&r2=1377482&view=diff
>>> ==
>>> --- incubator/ooo/trunk/main/external_deps.lst (original)
>>> +++ incubator/ooo/trunk/main/external_deps.lst Sun Aug 26 18:58:08 2012
>>> @@ -72,7 +72,7 @@ if ( true )
>>> if (SOLAR_JAVA == TRUE)
>>>MD5 = 17960f35b2239654ba608cf1f3e256b3
>>>name = lucene-2.9.4-src.tar.gz
>>> -URL1 = 
>>> http://www.us.apache.org/dist/lucene/java/2.9.4/lucene-2.9.4-src.tar.gz
>>> +URL1 = 
>>> http://archive.apache.org/dist/lucene/java/2.9.4/lucene-2.9.4-src.tar.gz
>>>URL2 = $(OOO_EXTRAS)$(MD5)-$(name)
>>># Fall back to a version in SVN from a prev

Re: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst

[Pedro Giffuni]

- Original Message -
 
> 
> On Sun, Aug 26, 2012 at 3:20 PM, Dave Fisher  
> wrote:
>>  Hi,
>> 
>>  We need to do more work to have proper compliance with Apache 
> Infrastructure policy in managing external dependencies.
>> 
>>  I may not be precisely correct and am looking for confirmation, but In 
> general i think we need to
>> 
>>  (1) Completely avoid using svn.apache.org. I don't think we are allowed 
> to do this even as a backup URL.
>> 
>>  (2) Use mirrors or maven for ASF dependencies where we use the current 
> release. If we use mirrors then archive.apache.org should be the backup for 
> the 
> mirror so that we aren't in trouble if the project has a release. If a maven 
> repository were used then there would be no issue.
>> 
>>  (3) If we use mirrors then we should allow the user to choose which mirror.
>> 
>>  If we decide to take the time to go the maven route. I can use the example 
> of ant and maven repos from the Apache POI build.xml.
>> 
>>  Notes about maven repos. Infra [1], maven central [2] and example of an 
> externally hosted repo [3]
>> 
>>  This area needs careful attention.
>> 
> 
> Note that this move is exactly the wrong thing to do if we want have
> buildbots build binaries that are assumed to be safe and therefore
> signable.  Instead of the security and verifiability of ASF-run host,
> we're putting the dependencies off to a dozen different remote sites,
> with no visibility into their site's mechanisms for vetting changes,
> access controls, auditability of changes, even basics like ensuring
> domain names are renewed and not poached by others.
>

This is not true. We use checksums precisely to certify the source tarballs
haven't been tampered with.


 
> Do we really think other websites are as secure as the ones that Infra
> operates?  If so we should move the source code to the other sites as
> well, right?
> 

Yes, upstream providers generate checksums and do proper
maintainance of their packages but perhaps more importantly by
working with them we can leverage their mirrors more efficiently.

I agree with Dave; we have to get rid of those tarballs
in SVN. Python 2.6.1 will be axed today, BTW.

 I haven't looked at Maven but it sounds like something
we should look at..

Pedro.

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Dave Fisher]

On Aug 26, 2012, at 12:42 PM, Dennis E. Hamilton wrote:

> FYI, concerning the matter of binaries distributed by the Apache OpenOffice 
> project.
> 
> I neglected to consider a case that Dave Fisher just raised here on ooo-dev: 
> Where the binary dependencies relied upon in an Apache OpenOffice binary 
> distribution are accessed from at build time and where those are identifiably 
> preserved for purposes of replication/confirmation and also for any future 
> forensic need.  That is an element in my topic (2) below.

Before we all light our hair on fire. I'm only saying that the build must not 
pull these out of svn, even as a backup. If you examine the current scripts 
that has been done already.

Regards,
Dave

> 
> Please do not comment on the general@ i.a.o thread.  It is a zombie in the 
> process of being burned at the stake.
> 
> - Dennis
> 
> -Original Message-
> From: Dennis E. Hamilton [mailto:orc...@apache.org] 
> Sent: Sunday, August 26, 2012 12:12
> To: gene...@incubator.apache.org
> Subject: RE: [VOTE] Apache OpenOffice Community Graduation Vote
> 
> Since my post was mentioned later on this thread, I thought I would summarize 
> what I have as the take-away from intervening discussion.  I have no 
> intention to deal with the use of language (i.e., semantics of "convenience") 
> and the way that tacit policy understanding is conveyed among Apache project 
> participants.
> 
> I will also refrain from any further additions to this topic.
> 
> TAKE-AWAYS
> 
> With regard to the production and delivery to users of authentic Apache 
> OpenOffice binary builds, there seem to be the following concerns (especially 
> for, but not limited to, Windows and Apple binaries and aggravated further by 
> the restraints that are growing around evolving "App Store" requirements for 
> consumer- and cloud-oriented platforms).  I see three cases:
> 
>   1. Authentication of binaries
>   2. Provenance of bundled binary dependencies 
>   3. Availability of source for inspection, audit, and provenance
> 
> 1. AUTHENTICATION OF BINARIES
> 
> The desire for binaries to be signed using digital signatures with private 
> keys held by the ASF is a natural concern for authentication of a variety of 
> binaries produced by Apache projects.
> 
> There appears to be agreement that any such signature introductions must be 
> done by ASF-authorized agents.  The conclusion is that infrastructure would 
> perform such signings.  These signings, by virtue of their modification of 
> the unsigned binary, will invalidate any external signatures that were 
> prepared as part of the release process.  (It is possible to extract the 
> internal signature and verify an external signature, if that is ever any 
> question about that.)
> 
> The signing party would have the reliance of the release-manager external 
> signatures and other attestation that the binary is produced from the release 
> sources.
> 
> This still leaves open additional concerns about the conditions under which 
> the binaries are produced and any difficulties that result.
> 
> An alternative is for the signing authority to also produce the binaries, 
> using the release sources directly on secured build machines.  There are a 
> number of technical problems that arise in this case, unless the release 
> candidates were built in the same manner but not (yet) signed.  That could 
> work.  It would also confirm that the binaries are indeed produced from the 
> release's sources using the parameters for the platform presumably also 
> included in the source materials.
> 
> The remaining question is, what is being attested to by the production of 
> binaries that are authenticated in this manner? Simply that they have been 
> built in this manner and that it was done using ASF infrastructure, the 
> integrity of which the ASF can be accountable for.  It is not an attestation 
> that there are no bugs, no security defects, or even that the IP provenance 
> is assured to be clean.  It is that the binary was produced under these 
> particular verifiable conditions from the source materials provided as part 
> of the source release along with dependencies on binaries incorporated in the 
> build.  
> 
> It also provides a strong differentiator for binaries, however they might be 
> identified, including even release candidates and developer builds, that were 
> not provided in this manner.
> 
> 2. PROVENANCE OF BUNDLED BINARY DEPENDENCIES
> 
> A complication in (1) is the incorporation of binary resources on which the 
> source-code release depends in order to be built.  These might be authorized 
> (and usually authenticated) redistributables having closed-source origins.  
> These might be authorized open-source libraries that must be used without 
> construction from sources in order for authentication of the dependency to be 
> preserved.  (E.g., there are security libraries that have NIST certification 
> on the binary library, never the source, and the c

AOO "long-term support" ?

[Fernando Cassia]

Hi,

I wonder if the ´new management´ at AOO ;) has any plans with regards to
´long term support´ for AOO?.

I mean... it´d be nice if we knew in advance that AOO 3.4.x will be
supported (bugfixes-stability and security issues if any) for the next ´x´
years.

Or just how long each version is supported (say, if an AOO 4.0 is released,
for how long AOO 3.4x will continue having security fixes, etc).

Not that I have any worries or needs on the particular... I was just
thinking about Ubuntu´s "LTS" releases scheme and the thought crossed my
mind if AOO project leaders had something like that in mind, or the talk of
release lifetime was ever thojught or even discussed...

So, I´m all ears. ;)
FC

-- 
During times of Universal Deceit, telling the truth becomes a revolutionary
act
- George Orwell

Re: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst

[Dave Fisher]

On Aug 26, 2012, at 12:38 PM, Rob Weir wrote:

> On Sun, Aug 26, 2012 at 3:20 PM, Dave Fisher  wrote:
>> Hi,
>> 
>> We need to do more work to have proper compliance with Apache Infrastructure 
>> policy in managing external dependencies.
>> 
>> I may not be precisely correct and am looking for confirmation, but In 
>> general i think we need to
>> 
>> (1) Completely avoid using svn.apache.org. I don't think we are allowed to 
>> do this even as a backup URL.
>> 
>> (2) Use mirrors or maven for ASF dependencies where we use the current 
>> release. If we use mirrors then archive.apache.org should be the backup for 
>> the mirror so that we aren't in trouble if the project has a release. If a 
>> maven repository were used then there would be no issue.
>> 
>> (3) If we use mirrors then we should allow the user to choose which mirror.
>> 
>> If we decide to take the time to go the maven route. I can use the example 
>> of ant and maven repos from the Apache POI build.xml.
>> 
>> Notes about maven repos. Infra [1], maven central [2] and example of an 
>> externally hosted repo [3]
>> 
>> This area needs careful attention.
>> 

Please take the time to study the Maven project before you attempt to reinvent 
it. [1]

> Note that this move is exactly the wrong thing to do if we want have
> buildbots build binaries that are assumed to be safe and therefore
> signable.  Instead of the security and verifiability of ASF-run host,
> we're putting the dependencies off to a dozen different remote sites,
> with no visibility into their site's mechanisms for vetting changes,
> access controls, auditability of changes, even basics like ensuring
> domain names are renewed and not poached by others.
> 
> Do we really think other websites are as secure as the ones that Infra
> operates?  If so we should move the source code to the other sites as
> well, right?

This is not the question. My comments were about using the ASF sites properly. 
Joe has told us that we are doing this out of policy.

> 
> No easy resolution of this, but we might mitigate the risk by putting
> all of the dependencies to Apache-Extras and load from there
> primarily.  And if at all possible make sure all change notifications
> from there get echoed to the ooo-committs lis.   We have a better
> chance of exercising now screwing up if we control rather than having
> multiple 3rd parties control.

We need to differentiate between ASF projects and third party projects. Look at 
the current process before you go nuts assuming that everything is changing.

> 
> Another option would be to use cryptographic means to ensure the
> integrity of the remote dependencies, e.g., detached signatures. That
> doesn't protect us from another website going down, temporarily or
> permanently, but it does allow us to verify that what we are
> downloading has not been tampered with.

This is already part of the current process. The signatures are in 
download_external_dependencies.pl. The Central Maven Repository uses these as 
well.

[1] http://maven.apache.org/

> 


> 
> -Rob
> 
> 
>> The current script is here: main/solenv/bin/download_external_dependencies.pl
>> 
>> Regards,
>> Dave
>> 
>> [1] http://apache.org/dev/repository-faq.html  and
>> [2] http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>> [3] 
>> http://repo.maven.apache.org/maven2/javax/activation/activation/1.0.2/activation-1.0.2.pom
>> 
>> 
>> On Aug 26, 2012, at 11:58 AM, w...@apache.org wrote:
>> 
>>> Author: wave
>>> Date: Sun Aug 26 18:58:08 2012
>>> New Revision: 1377482
>>> 
>>> URL: http://svn.apache.org/viewvc?rev=1377482&view=rev
>>> Log:
>>> one more small step to infra compliance. still to do removing use of svn as 
>>> a backup and for current releases of ASF software the archive is not proper 
>>> - either a mirror or the maven repository is required.
>>> 
>>> Modified:
>>>   incubator/ooo/trunk/main/external_deps.lst
>>> 
>>> Modified: incubator/ooo/trunk/main/external_deps.lst
>>> URL: 
>>> http://svn.apache.org/viewvc/incubator/ooo/trunk/main/external_deps.lst?rev=1377482&r1=1377481&r2=1377482&view=diff
>>> ==
>>> --- incubator/ooo/trunk/main/external_deps.lst (original)
>>> +++ incubator/ooo/trunk/main/external_deps.lst Sun Aug 26 18:58:08 2012
>>> @@ -72,7 +72,7 @@ if ( true )
>>> if (SOLAR_JAVA == TRUE)
>>>MD5 = 17960f35b2239654ba608cf1f3e256b3
>>>name = lucene-2.9.4-src.tar.gz
>>> -URL1 = 
>>> http://www.us.apache.org/dist/lucene/java/2.9.4/lucene-2.9.4-src.tar.gz
>>> +URL1 = 
>>> http://archive.apache.org/dist/lucene/java/2.9.4/lucene-2.9.4-src.tar.gz
>>>URL2 = $(OOO_EXTRAS)$(MD5)-$(name)
>>># Fall back to a version in SVN from a previous revsion.
>>>URL3 = 
>>> http://svn.apache.org/repos/asf/!svn/bc/1337615/incubator/ooo/trunk/ext_sources/$(MD5)-$(name)
>>> 
>>> 
>> 

Re: Open-office downloading site - FLV player advertisement

[Roberto Galoppini]

On Sun, Aug 26, 2012 at 6:29 PM, Jonas Küng  wrote:

>  Hello
>
> Today I have downloaded the new open office version. Unfortunately I
> clicked on the big green button "Download" of the FLV player advertisement
> (see attachement with printsceen) because I thought the download of open
> office have not started automatically and I expected that button as one of
> op office. So far no problem. But then my antivirus programm indicated me
> twice that the downloaded file of that FLV player is infected by viruses.
> So pleace have a look on this advertisement.
>
> Thanks a lot
>
> Jonas Küng
>

Hi Jonas,

 if you run in a similar problem please advise me about the exact URL, we
need that to prevent it to happen again in the future.

Thanks,

Roberto

-- 

This e- mail message is intended only for the named recipient(s) above. It 
may contain confidential and privileged information. If you are not the 
intended recipient you are hereby notified that any dissemination, 
distribution or copying of this e-mail and any attachment(s) is strictly 
prohibited. If you have received this e-mail in error, please immediately 
notify the sender by replying to this e-mail and delete the message and any 
attachment(s) from your system. Thank you.

RE: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst

[Dennis E. Hamilton]

+1 on preserving the provenance and integrity of binary dependencies.

I'd go with external signatures *and* hosting the specific artifacts on a 
reliable ASF location for preservation along with all ASF project sources that 
depended on those specific artifacts in any sort of review, release of 
authenticated binaries, etc.

 - Dennis

-Original Message-
From: Rob Weir [mailto:robw...@apache.org] 
Sent: Sunday, August 26, 2012 12:38
To: ooo-dev@incubator.apache.org
Subject: Re: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst

On Sun, Aug 26, 2012 at 3:20 PM, Dave Fisher  wrote:
> Hi,
>
> We need to do more work to have proper compliance with Apache Infrastructure 
> policy in managing external dependencies.
>
> I may not be precisely correct and am looking for confirmation, but In 
> general i think we need to
>
> (1) Completely avoid using svn.apache.org. I don't think we are allowed to do 
> this even as a backup URL.
>
> (2) Use mirrors or maven for ASF dependencies where we use the current 
> release. If we use mirrors then archive.apache.org should be the backup for 
> the mirror so that we aren't in trouble if the project has a release. If a 
> maven repository were used then there would be no issue.
>
> (3) If we use mirrors then we should allow the user to choose which mirror.
>
> If we decide to take the time to go the maven route. I can use the example of 
> ant and maven repos from the Apache POI build.xml.
>
> Notes about maven repos. Infra [1], maven central [2] and example of an 
> externally hosted repo [3]
>
> This area needs careful attention.
>

Note that this move is exactly the wrong thing to do if we want have
buildbots build binaries that are assumed to be safe and therefore
signable.  Instead of the security and verifiability of ASF-run host,
we're putting the dependencies off to a dozen different remote sites,
with no visibility into their site's mechanisms for vetting changes,
access controls, auditability of changes, even basics like ensuring
domain names are renewed and not poached by others.

Do we really think other websites are as secure as the ones that Infra
operates?  If so we should move the source code to the other sites as
well, right?

No easy resolution of this, but we might mitigate the risk by putting
all of the dependencies to Apache-Extras and load from there
primarily.  And if at all possible make sure all change notifications
from there get echoed to the ooo-committs lis.   We have a better
chance of exercising now screwing up if we control rather than having
multiple 3rd parties control.

Another option would be to use cryptographic means to ensure the
integrity of the remote dependencies, e.g., detached signatures. That
doesn't protect us from another website going down, temporarily or
permanently, but it does allow us to verify that what we are
downloading has not been tampered with.

-Rob


> The current script is here: main/solenv/bin/download_external_dependencies.pl
>
> Regards,
> Dave
>
> [1] http://apache.org/dev/repository-faq.html  and
> [2] http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> [3] 
> http://repo.maven.apache.org/maven2/javax/activation/activation/1.0.2/activation-1.0.2.pom
>
>
> On Aug 26, 2012, at 11:58 AM, w...@apache.org wrote:
>
>> Author: wave
>> Date: Sun Aug 26 18:58:08 2012
>> New Revision: 1377482
>>
>> URL: http://svn.apache.org/viewvc?rev=1377482&view=rev
>> Log:
>> one more small step to infra compliance. still to do removing use of svn as 
>> a backup and for current releases of ASF software the archive is not proper 
>> - either a mirror or the maven repository is required.
>>
>> Modified:
>>incubator/ooo/trunk/main/external_deps.lst
>>
>> Modified: incubator/ooo/trunk/main/external_deps.lst
>> URL: 
>> http://svn.apache.org/viewvc/incubator/ooo/trunk/main/external_deps.lst?rev=1377482&r1=1377481&r2=1377482&view=diff
>> ==
>> --- incubator/ooo/trunk/main/external_deps.lst (original)
>> +++ incubator/ooo/trunk/main/external_deps.lst Sun Aug 26 18:58:08 2012
>> @@ -72,7 +72,7 @@ if ( true )
>> if (SOLAR_JAVA == TRUE)
>> MD5 = 17960f35b2239654ba608cf1f3e256b3
>> name = lucene-2.9.4-src.tar.gz
>> -URL1 = 
>> http://www.us.apache.org/dist/lucene/java/2.9.4/lucene-2.9.4-src.tar.gz
>> +URL1 = 
>> http://archive.apache.org/dist/lucene/java/2.9.4/lucene-2.9.4-src.tar.gz
>> URL2 = $(OOO_EXTRAS)$(MD5)-$(name)
>> # Fall back to a version in SVN from a previous revsion.
>> URL3 = 
>> http://svn.apache.org/repos/asf/!svn/bc/1337615/incubator/ooo/trunk/ext_sources/$(MD5)-$(name)
>>
>>
>

FW: [VOTE] Apache OpenOffice Community Graduation Vote

[Dennis E. Hamilton]

FYI, concerning the matter of binaries distributed by the Apache OpenOffice 
project.

I neglected to consider a case that Dave Fisher just raised here on ooo-dev: 
Where the binary dependencies relied upon in an Apache OpenOffice binary 
distribution are accessed from at build time and where those are identifiably 
preserved for purposes of replication/confirmation and also for any future 
forensic need.  That is an element in my topic (2) below.

Please do not comment on the general@ i.a.o thread.  It is a zombie in the 
process of being burned at the stake.

 - Dennis

-Original Message-
From: Dennis E. Hamilton [mailto:orc...@apache.org] 
Sent: Sunday, August 26, 2012 12:12
To: gene...@incubator.apache.org
Subject: RE: [VOTE] Apache OpenOffice Community Graduation Vote

Since my post was mentioned later on this thread, I thought I would summarize 
what I have as the take-away from intervening discussion.  I have no intention 
to deal with the use of language (i.e., semantics of "convenience") and the way 
that tacit policy understanding is conveyed among Apache project participants.

I will also refrain from any further additions to this topic.

TAKE-AWAYS

With regard to the production and delivery to users of authentic Apache 
OpenOffice binary builds, there seem to be the following concerns (especially 
for, but not limited to, Windows and Apple binaries and aggravated further by 
the restraints that are growing around evolving "App Store" requirements for 
consumer- and cloud-oriented platforms).  I see three cases:

   1. Authentication of binaries
   2. Provenance of bundled binary dependencies 
   3. Availability of source for inspection, audit, and provenance

 1. AUTHENTICATION OF BINARIES

The desire for binaries to be signed using digital signatures with private keys 
held by the ASF is a natural concern for authentication of a variety of 
binaries produced by Apache projects.

There appears to be agreement that any such signature introductions must be 
done by ASF-authorized agents.  The conclusion is that infrastructure would 
perform such signings.  These signings, by virtue of their modification of the 
unsigned binary, will invalidate any external signatures that were prepared as 
part of the release process.  (It is possible to extract the internal signature 
and verify an external signature, if that is ever any question about that.)

The signing party would have the reliance of the release-manager external 
signatures and other attestation that the binary is produced from the release 
sources.

This still leaves open additional concerns about the conditions under which the 
binaries are produced and any difficulties that result.

An alternative is for the signing authority to also produce the binaries, using 
the release sources directly on secured build machines.  There are a number of 
technical problems that arise in this case, unless the release candidates were 
built in the same manner but not (yet) signed.  That could work.  It would also 
confirm that the binaries are indeed produced from the release's sources using 
the parameters for the platform presumably also included in the source 
materials.

The remaining question is, what is being attested to by the production of 
binaries that are authenticated in this manner? Simply that they have been 
built in this manner and that it was done using ASF infrastructure, the 
integrity of which the ASF can be accountable for.  It is not an attestation 
that there are no bugs, no security defects, or even that the IP provenance is 
assured to be clean.  It is that the binary was produced under these particular 
verifiable conditions from the source materials provided as part of the source 
release along with dependencies on binaries incorporated in the build.  

It also provides a strong differentiator for binaries, however they might be 
identified, including even release candidates and developer builds, that were 
not provided in this manner.

2. PROVENANCE OF BUNDLED BINARY DEPENDENCIES

A complication in (1) is the incorporation of binary resources on which the 
source-code release depends in order to be built.  These might be authorized 
(and usually authenticated) redistributables having closed-source origins.  
These might be authorized open-source libraries that must be used without 
construction from sources in order for authentication of the dependency to be 
preserved.  (E.g., there are security libraries that have NIST certification on 
the binary library, never the source, and the certification is also sustained 
only when the library is used with specific tooling.)

For whatever reason, it is appropriate and preferable that the binary form of a 
dependency be relied upon, whether a jar file, a static library, or a dynamic 
library (DLL or SO) that becomes incorporated in the authenticated binary.

The specific dependencies of such a nature would need to be accounted for as 
part of the authenticated build.  That r

Re: [DL Website] Prototype of an automatic table with download links

[Dave Fisher]

On Aug 26, 2012, at 11:05 AM, Marcus (OOo) wrote:

> Hi all,
> 
> as promized on Friday I've adjusted the existing automatism to the lastest 
> AOO 3.4.1 parameters.
> 
> The most recent webpage is here:
> http://ooo-site.staging.apache.org/download/test/other_print.html

There is one change needed with the source downloads. Please use the Apache 
Mirrors and not dist directly for the packages. See [1].

Should the language packs be mixed with the full installation sets? If so then 
maybe the language fields should span two rows?

Regards,
Dave

[1] http://incubator.apache.org/openofficeorg/downloads.html


> 
> I'm open for opinions. Otherwise I can put it easily to the production 
> website as the new "other.html".
> 
> Marcus

Re: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst

[Rob Weir]

On Sun, Aug 26, 2012 at 3:20 PM, Dave Fisher  wrote:
> Hi,
>
> We need to do more work to have proper compliance with Apache Infrastructure 
> policy in managing external dependencies.
>
> I may not be precisely correct and am looking for confirmation, but In 
> general i think we need to
>
> (1) Completely avoid using svn.apache.org. I don't think we are allowed to do 
> this even as a backup URL.
>
> (2) Use mirrors or maven for ASF dependencies where we use the current 
> release. If we use mirrors then archive.apache.org should be the backup for 
> the mirror so that we aren't in trouble if the project has a release. If a 
> maven repository were used then there would be no issue.
>
> (3) If we use mirrors then we should allow the user to choose which mirror.
>
> If we decide to take the time to go the maven route. I can use the example of 
> ant and maven repos from the Apache POI build.xml.
>
> Notes about maven repos. Infra [1], maven central [2] and example of an 
> externally hosted repo [3]
>
> This area needs careful attention.
>

Note that this move is exactly the wrong thing to do if we want have
buildbots build binaries that are assumed to be safe and therefore
signable.  Instead of the security and verifiability of ASF-run host,
we're putting the dependencies off to a dozen different remote sites,
with no visibility into their site's mechanisms for vetting changes,
access controls, auditability of changes, even basics like ensuring
domain names are renewed and not poached by others.

Do we really think other websites are as secure as the ones that Infra
operates?  If so we should move the source code to the other sites as
well, right?

No easy resolution of this, but we might mitigate the risk by putting
all of the dependencies to Apache-Extras and load from there
primarily.  And if at all possible make sure all change notifications
from there get echoed to the ooo-committs lis.   We have a better
chance of exercising now screwing up if we control rather than having
multiple 3rd parties control.

Another option would be to use cryptographic means to ensure the
integrity of the remote dependencies, e.g., detached signatures. That
doesn't protect us from another website going down, temporarily or
permanently, but it does allow us to verify that what we are
downloading has not been tampered with.

-Rob


> The current script is here: main/solenv/bin/download_external_dependencies.pl
>
> Regards,
> Dave
>
> [1] http://apache.org/dev/repository-faq.html  and
> [2] http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> [3] 
> http://repo.maven.apache.org/maven2/javax/activation/activation/1.0.2/activation-1.0.2.pom
>
>
> On Aug 26, 2012, at 11:58 AM, w...@apache.org wrote:
>
>> Author: wave
>> Date: Sun Aug 26 18:58:08 2012
>> New Revision: 1377482
>>
>> URL: http://svn.apache.org/viewvc?rev=1377482&view=rev
>> Log:
>> one more small step to infra compliance. still to do removing use of svn as 
>> a backup and for current releases of ASF software the archive is not proper 
>> - either a mirror or the maven repository is required.
>>
>> Modified:
>>incubator/ooo/trunk/main/external_deps.lst
>>
>> Modified: incubator/ooo/trunk/main/external_deps.lst
>> URL: 
>> http://svn.apache.org/viewvc/incubator/ooo/trunk/main/external_deps.lst?rev=1377482&r1=1377481&r2=1377482&view=diff
>> ==
>> --- incubator/ooo/trunk/main/external_deps.lst (original)
>> +++ incubator/ooo/trunk/main/external_deps.lst Sun Aug 26 18:58:08 2012
>> @@ -72,7 +72,7 @@ if ( true )
>> if (SOLAR_JAVA == TRUE)
>> MD5 = 17960f35b2239654ba608cf1f3e256b3
>> name = lucene-2.9.4-src.tar.gz
>> -URL1 = 
>> http://www.us.apache.org/dist/lucene/java/2.9.4/lucene-2.9.4-src.tar.gz
>> +URL1 = 
>> http://archive.apache.org/dist/lucene/java/2.9.4/lucene-2.9.4-src.tar.gz
>> URL2 = $(OOO_EXTRAS)$(MD5)-$(name)
>> # Fall back to a version in SVN from a previous revsion.
>> URL3 = 
>> http://svn.apache.org/repos/asf/!svn/bc/1337615/incubator/ooo/trunk/ext_sources/$(MD5)-$(name)
>>
>>
>

Re: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst

[Dave Fisher]

Hi,

We need to do more work to have proper compliance with Apache Infrastructure 
policy in managing external dependencies.

I may not be precisely correct and am looking for confirmation, but In general 
i think we need to

(1) Completely avoid using svn.apache.org. I don't think we are allowed to do 
this even as a backup URL.

(2) Use mirrors or maven for ASF dependencies where we use the current release. 
If we use mirrors then archive.apache.org should be the backup for the mirror 
so that we aren't in trouble if the project has a release. If a maven 
repository were used then there would be no issue.

(3) If we use mirrors then we should allow the user to choose which mirror.

If we decide to take the time to go the maven route. I can use the example of 
ant and maven repos from the Apache POI build.xml.

Notes about maven repos. Infra [1], maven central [2] and example of an 
externally hosted repo [3]

This area needs careful attention.

The current script is here: main/solenv/bin/download_external_dependencies.pl

Regards,
Dave

[1] http://apache.org/dev/repository-faq.html  and 
[2] http://maven.apache.org/guides/mini/guide-central-repository-upload.html
[3] 
http://repo.maven.apache.org/maven2/javax/activation/activation/1.0.2/activation-1.0.2.pom


On Aug 26, 2012, at 11:58 AM, w...@apache.org wrote:

> Author: wave
> Date: Sun Aug 26 18:58:08 2012
> New Revision: 1377482
> 
> URL: http://svn.apache.org/viewvc?rev=1377482&view=rev
> Log:
> one more small step to infra compliance. still to do removing use of svn as a 
> backup and for current releases of ASF software the archive is not proper - 
> either a mirror or the maven repository is required.
> 
> Modified:
>incubator/ooo/trunk/main/external_deps.lst
> 
> Modified: incubator/ooo/trunk/main/external_deps.lst
> URL: 
> http://svn.apache.org/viewvc/incubator/ooo/trunk/main/external_deps.lst?rev=1377482&r1=1377481&r2=1377482&view=diff
> ==
> --- incubator/ooo/trunk/main/external_deps.lst (original)
> +++ incubator/ooo/trunk/main/external_deps.lst Sun Aug 26 18:58:08 2012
> @@ -72,7 +72,7 @@ if ( true )
> if (SOLAR_JAVA == TRUE)
> MD5 = 17960f35b2239654ba608cf1f3e256b3
> name = lucene-2.9.4-src.tar.gz
> -URL1 = 
> http://www.us.apache.org/dist/lucene/java/2.9.4/lucene-2.9.4-src.tar.gz
> +URL1 = 
> http://archive.apache.org/dist/lucene/java/2.9.4/lucene-2.9.4-src.tar.gz
> URL2 = $(OOO_EXTRAS)$(MD5)-$(name)
> # Fall back to a version in SVN from a previous revsion.
> URL3 = 
> http://svn.apache.org/repos/asf/!svn/bc/1337615/incubator/ooo/trunk/ext_sources/$(MD5)-$(name)
> 
> 

Re: Something wrong in download page for Linux users

[Marcus (OOo)]

Am 08/24/2012 11:52 PM, schrieb Marcus (OOo):

Am 08/23/2012 04:24 PM, schrieb Ariel Constenla-Haile:


Hi Marcus,

On Fri, May 18, 2012 at 01:49:19AM +0200, Marcus (OOo) wrote:

Am 05/18/2012 01:29 AM, schrieb Ariel Constenla-Haile:

On Fri, May 18, 2012 at 12:26:41AM +0200, Marcus (OOo) wrote:


The system and the browser are 64 bits, the package is 32 bits.


Interesting. The browser shows that the platform is i686 (= x86) and
the user agents says x86_64. Haven't seen this before.

OK, which value is right when you don't know the truth? ;-)


just blame it on Google :)

http://code.google.com/p/chromium/issues/detail?id=44905


Interesting, even Google software has old bugs. :-P


Duplicated by this one?
http://code.google.com/p/chromium/issues/detail?id=128167


Great. When this is solved somewhen, we can check our DL logic
again. I'll add this to the Wiki page.



FYI this is fixed now in Chrome, according to the browser values shown
by http://www.openoffice.org/download/test/analyze.html


Ah, thank you for the hint. I will analyze the data what needs to be
updated.

BTW:
Great to have this little test webpage online, isn't it? ;-)


This should work now with the recent change from Oliver.

Can you confirm this especially for Chrome?

Thanks

Marcus




Variables from the browser Values

navigator.platform Linux x86_64
navigator.platform.toLowerCase() linux x86_64
navigator.language en-US
navigator.userLanguage undefined
navigator.systemLanguage undefined
navigator.userAgent Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.1
(KHTML, like Gecko) Chrome/21.0.1180.81 Safari/537.1
navigator.userAgent.toLowerCase() mozilla/5.0 (x11; linux x86_64)
applewebkit/537.1 (khtml, like gecko) chrome/21.0.1180.81 safari/537.1
navigator.javaEnabled() Yes


But the download page is providing 32 bits to download (though the text
says "Click to start downloading the most recent version for Linux
64-bit (RPM and English (US)"):


JavaScript functions from the DL scripts Return values
getLink( VERSION, LANGUAGE, MIRROR, SCHEMA )
http://sourceforge.net/projects/openofficeorg.mirror/files/stable/3.4.1/Apache_OpenOffice_incubating_3.4.1_Linux_x86_install-rpm_en-US.tar.gz/download

getArray( LANGUAGE ) here,English (US),English
(US),http://www.openoffice.org/download/other.html,y
getPlatform( LANGUAGE, SCHEMA ) Linux 64-bit (RPM)
getLanguage( LANGUAGE ) English (US)
getLanguageISO( LANGUAGE ) en-US
sourceforge_getLink( VERSION, LANGUAGE, SCHEMA )
http://sourceforge.net/projects/openofficeorg.mirror/files/stable/3.4.1/Apache_OpenOffice_incubating_3.4.1_Linux_x86_install-rpm_en-US.tar.gz/download

apache_getLink( VERSION, LANGUAGE, SCHEMA )
http://www.apache.org/dyn/closer.cgi/incubator/ooo/files/stable/3.4.1/Apache_OpenOffice_incubating_3.4.1_Linux_x86_install-rpm_en-US.tar.gz

apache_getChecksum( VERSION, LANGUAGE, SCHEMA, HASH )
http://www.apache.org/dist/incubator/ooo/files/stable/3.4.1/Apache_OpenOffice_incubating_3.4.1_Linux_x86_install-rpm_en-US.tar.gz.md5

mirrorbrain_getPlatformForMirror( LANGUAGE, SCHEMA )
Linux_x86_install-rpm
mirrorbrain_getFilename( VERSION, LANGUAGE, SCHEMA )
Apache_OpenOffice_incubating_3.4.1_Linux_x86_install-rpm_en-US.tar.gz
mirrorbrain_getExtension( LANGUAGE, SCHEMA ) .tar.gz
hasMirrorLink( LANGUAGE ) true


Google Chrome Info:

Name : google-chrome-beta
Arch : x86_64
Version : 21.0.1180.81
Release : 151980
Size : 125 M
Repo : installed
From repo : google-chrome
Summary : Google Chrome
URL : http://chrome.google.com/
License : Multiple, see http://chrome.google.com/

Re: Open-office downloading site - FLV player advertisement

[imacat]

Dear Jonas,

I believe you missed the attachment screen capture.

On 2012/08/27 00:29, Jonas Küng said:
> 
> Hello
> 
> Today I have downloaded the new open office version. Unfortunately I clicked 
> on the big green button "Download" of the FLV player advertisement (see 
> attachement with printsceen) because I thought the download of open office 
> have not started automatically and I expected that button as one of op 
> office. So far no problem. But then my antivirus programm indicated me twice 
> that the downloaded file of that FLV player is infected by viruses. So pleace 
> have a look on this advertisement.
> 
> Thanks a lot
> 
> Jonas Küng
> 

-- 
Best regards,
imacat ^_*' 
PGP Key http://www.imacat.idv.tw/me/pgpkey.asc

<> News: http://www.wov.idv.tw/
Tavern IMACAT's http://www.imacat.idv.tw/
Woman in FOSS in Taiwan http://wofoss.blogspot.com/
Apache OpenOffice http://www.openoffice.org/
EducOO/OOo4Kids Taiwan http://www.educoo.tw/



signature.asc
Description: OpenPGP digital signature

[DL Website] Prototype of an automatic table with download links

[Marcus (OOo)]

Hi all,

as promized on Friday I've adjusted the existing automatism to the 
lastest AOO 3.4.1 parameters.


The most recent webpage is here:
http://ooo-site.staging.apache.org/download/test/other_print.html

I'm open for opinions. Otherwise I can put it easily to the production 
website as the new "other.html".


Marcus

Re: [WWW]Some trouble with the new URLs for the forums

[imacat]

On 2012/08/27 00:15, Dave Fisher said:
> 
> On Aug 26, 2012, at 8:03 AM, RGB ES wrote:
> 
>> 2012/8/26 Rob Weir :
>>> On Sun, Aug 26, 2012 at 8:31 AM, RGB ES  wrote:
 Adding to the (lack of) redirection problem between the old and the
 new URL expressed on other threads, there are other problems reported
 by users. The first one is that forum notifications still arrive with
 only the old URL. Also, there are users experimenting problems with
 automatic log-in not working on the new URL.

 Another point that came to my mind is what happens with web crawler
 bots registered on the forums: I think that google, yahoo and all the
 others are still logging on (and indexing) the old URLs and ignoring
 the new ones. In fact, when you perform a web search on google, for
 example, about AOO all results that point to the forums show the old
 URL...

>>>
>>> Are we exposing two different URL's for the forums, with the same
>>> content?
>>
>> Exactly. You can enter the forum from both, the user.service... and
>> the forum.openoffice... addresses.
> 
> I know what we need to do. We need to either:
> 
> (1) Deploy Apache Traffic Server in front of the Forums on the ooo-forums VM. 
> We have that on ooo-wiki which is why that redirection works better.
> 
> (2) Modify the apache.conf on ooo-forums VM to do a permanent redirection.

This part I'm planning.  Not done yet because there is still problem
with forum session handling, and I'm still investigating.  Any hint is
welcome.

> 
> There are probably actions the forum sysadmin needs to take.
> 
> The runbooks for both ooo-wiki and ooo-forums need to be checked if they are 
> fully up to date. TerryE's falling out with Infra was in part over Infra's 
> understandable requirement that the runbooks be quickly consumable by anyone 
> in text. He refused and so these are at risk.
> 
> Regards,
> Dave
> 
>>
>>
>> If so that is bad for Google.  It could penalize the forums
>>> in search results due to the "duplicate content penalty"  (essentially
>>> it looks spammy to have identical content at multiple different
>>> URL's).
>>>
>>> See:  
>>> http://googlewebmastercentral.blogspot.com/2008/09/demystifying-duplicate-content-penalty.html
>>>
>>> The preferred way is to either:
>>>
>>> 1) Redirect from the old URL to the new URL
>>>
>>> or
>>>
>>> 2) Use the re="canonical" directive to ;et Google know what the
>>> preferred URL is;
>>> http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html
>>>
>>>
 Could a redirection solve all this problems at once?

 Regards
 Ricardo
> 


-- 
Best regards,
imacat ^_*' 
PGP Key http://www.imacat.idv.tw/me/pgpkey.asc

<> News: http://www.wov.idv.tw/
Tavern IMACAT's http://www.imacat.idv.tw/
Woman in FOSS in Taiwan http://wofoss.blogspot.com/
Apache OpenOffice http://www.openoffice.org/
EducOO/OOo4Kids Taiwan http://www.educoo.tw/



signature.asc
Description: OpenPGP digital signature

Open-office downloading site - FLV player advertisement

[Jonas Küng]

Hello

Today I have downloaded the new open office version. Unfortunately I clicked on 
the big green button "Download" of the FLV player advertisement (see 
attachement with printsceen) because I thought the download of open office have 
not started automatically and I expected that button as one of op office. So 
far no problem. But then my antivirus programm indicated me twice that the 
downloaded file of that FLV player is infected by viruses. So pleace have a 
look on this advertisement.

Thanks a lot

Jonas Küng
  

Re: proposed new directory structure for future releases

[Marcus (OOo)]

Am 08/26/2012 02:26 AM, schrieb Rob Weir:

On Sat, Aug 25, 2012 at 5:36 PM, Kay Schenk  wrote:



On 08/25/2012 01:28 PM, Andrea Pescetti wrote:


On 23/08/2012 22:06, Marcus (OOo) wrote:


Also IMHO no need to separate between the languages.
Furthermore, when you have to check for a potential error, then you you
just need to verify this in a single directory and not more.
/stable/VERSION/



The rest is OK, but removing even the languages subdirectories is
probably too much: we already have 20 languages and they could
theoretically reach 100+, so it would make sense to preserve the
individual subdirectories "en-US", "de", "it" and so on.

Regards,
Andrea.



+1 with Andrea on this one. We should leave the languages in separate
directories. And, if folks do "browsing" on SourceForge instead of using our
download logic, this will make things easier for that purpose as well.



+1

It also makes it easier if someone wants to burn a CD for just a
single language.


OK, so our most recent opinion is the following:

/stable/VERSION//...

Anyone else with different suggestions?

Marcus

Re: Extension downloading problem

[Dave Fisher]

On Aug 26, 2012, at 10:17 AM, Roberto Galoppini wrote:

> On Sun, Aug 26, 2012 at 1:53 PM, Andrea Pescetti wrote:
> 
>> Rob Weir wrote:
>> 
>>> Also, I wonder if it would be worth submitting a patch for Apache.  It
>>> looks like they have the other content types used by OpenOffice, but
>>> not oxt files:
>>> http://svn.apache.org/repos/**asf/httpd/httpd/trunk/docs/**
>>> conf/mime.types
>>> 
>> 
>> Actually, it seems it's already been there for a while:
>> $ svn annotate mime.types  | grep oxt
>> 571614   fielding application/vnd.openofficeorg.**extension
>> oxt
>> $ svn log | grep 571614
>> r571614 | fielding | 2007-08-31 23:57:29 +0200(ven, 31 ago 2007) | 3 lines
>> 
>> and if I put an extension on my people.apache.org account I see it's
>> served correctly (of course, this has nothing to do with the problem under
>> discussion; but if problems come from an incorrect MIME type, then people
>> reporting the problem should be able to download
>> http://people.apache.org/~**pescetti/tmp/dict-it.oxt
>> correctly).
>> 
> 
> I confirm your suspects, it's a MIME config issue. I tested SourceForge
> master, that works just fine, but not all mirrors do manage it correctly.
> As a short-term solution for all extensions - either hosted at SourceForge
> or at third party website - we report the following note:
> 
> *Note: some browsers may download the extension as a .zip file; if this
> happens rename the downloaded file from .zip to .oxt*
> 
> We can then run a communication plan to inform both mirror and
> third-parties.

+1.

I wonder if these are all NGINX servers.

IIRC The ASF requires all Apache Mirrors to use Apache HTTPD Servers, but I'm 
certainly not proposing that GeekNet do the same.

Regards,
Dave



> 
> Roberto
> 
> 
>> 
>> Regards,
>>  Andrea.
>> 
> 
> -- 
> 
> This e- mail message is intended only for the named recipient(s) above. It 
> may contain confidential and privileged information. If you are not the 
> intended recipient you are hereby notified that any dissemination, 
> distribution or copying of this e-mail and any attachment(s) is strictly 
> prohibited. If you have received this e-mail in error, please immediately 
> notify the sender by replying to this e-mail and delete the message and any 
> attachment(s) from your system. Thank you.
> 

Re: Extension downloading problem

[Roberto Galoppini]

On Sun, Aug 26, 2012 at 1:53 PM, Andrea Pescetti wrote:

> Rob Weir wrote:
>
>> Also, I wonder if it would be worth submitting a patch for Apache.  It
>> looks like they have the other content types used by OpenOffice, but
>> not oxt files:
>> http://svn.apache.org/repos/**asf/httpd/httpd/trunk/docs/**
>> conf/mime.types
>>
>
> Actually, it seems it's already been there for a while:
> $ svn annotate mime.types  | grep oxt
> 571614   fielding application/vnd.openofficeorg.**extension
> oxt
> $ svn log | grep 571614
> r571614 | fielding | 2007-08-31 23:57:29 +0200(ven, 31 ago 2007) | 3 lines
>
> and if I put an extension on my people.apache.org account I see it's
> served correctly (of course, this has nothing to do with the problem under
> discussion; but if problems come from an incorrect MIME type, then people
> reporting the problem should be able to download
> http://people.apache.org/~**pescetti/tmp/dict-it.oxt
> correctly).
>

I confirm your suspects, it's a MIME config issue. I tested SourceForge
master, that works just fine, but not all mirrors do manage it correctly.
As a short-term solution for all extensions - either hosted at SourceForge
or at third party website - we report the following note:

*Note: some browsers may download the extension as a .zip file; if this
happens rename the downloaded file from .zip to .oxt*

We can then run a communication plan to inform both mirror and
third-parties.

Roberto


>
> Regards,
>   Andrea.
>

-- 

This e- mail message is intended only for the named recipient(s) above. It 
may contain confidential and privileged information. If you are not the 
intended recipient you are hereby notified that any dissemination, 
distribution or copying of this e-mail and any attachment(s) is strictly 
prohibited. If you have received this e-mail in error, please immediately 
notify the sender by replying to this e-mail and delete the message and any 
attachment(s) from your system. Thank you.

Re: [DISCUSS][Linux]Drop distro specific RPMs

[RGB ES]

2012/8/26 Kay Schenk :
> On Sun, Aug 26, 2012 at 5:13 AM, RGB ES  wrote:
>
>> This time I installed not the "suse" desktop integration RPM but the
>> "freedesktop" one, and it worked without problems. If someone confirm
>> that this is the same for fedora and mandriva then I think we can
>> safely drop those distro specific RPMs and offer only one, like we
>> offer only one .deb on the debian packages.
>>
>> What do you think?
>>
>> Regards
>> Ricardo
>>
>
> This is interesting. I should try this one as well and see what happens.
>
> Can you provide further details?
>
> What distro are you using? What window manager are you using, etc.
>

openSUSE 11.4, 64 bits, with KDE SC 4.8.4. On a couple of weeks maybe
I'll try with openSUSE 12.2.

The freedesktop package provided the menu entries, the mime type
icons... and I can use krunner to launch any AOO app.

Regards
Ricardo

Re: [DISCUSS][Linux]Drop distro specific RPMs

[Kay Schenk]

On Sun, Aug 26, 2012 at 5:13 AM, RGB ES  wrote:

> This time I installed not the "suse" desktop integration RPM but the
> "freedesktop" one, and it worked without problems. If someone confirm
> that this is the same for fedora and mandriva then I think we can
> safely drop those distro specific RPMs and offer only one, like we
> offer only one .deb on the debian packages.
>
> What do you think?
>
> Regards
> Ricardo
>

This is interesting. I should try this one as well and see what happens.

Can you provide further details?

What distro are you using? What window manager are you using, etc.



-- 

MzK

"As a child my family's menu consisted of two choices:
take it or leave it. "
   -- Buddy Hackett

Re: [WWW]Some trouble with the new URLs for the forums

[Dave Fisher]

On Aug 26, 2012, at 8:03 AM, RGB ES wrote:

> 2012/8/26 Rob Weir :
>> On Sun, Aug 26, 2012 at 8:31 AM, RGB ES  wrote:
>>> Adding to the (lack of) redirection problem between the old and the
>>> new URL expressed on other threads, there are other problems reported
>>> by users. The first one is that forum notifications still arrive with
>>> only the old URL. Also, there are users experimenting problems with
>>> automatic log-in not working on the new URL.
>>> 
>>> Another point that came to my mind is what happens with web crawler
>>> bots registered on the forums: I think that google, yahoo and all the
>>> others are still logging on (and indexing) the old URLs and ignoring
>>> the new ones. In fact, when you perform a web search on google, for
>>> example, about AOO all results that point to the forums show the old
>>> URL...
>>> 
>> 
>> Are we exposing two different URL's for the forums, with the same
>> content?
> 
> Exactly. You can enter the forum from both, the user.service... and
> the forum.openoffice... addresses.

I know what we need to do. We need to either:

(1) Deploy Apache Traffic Server in front of the Forums on the ooo-forums VM. 
We have that on ooo-wiki which is why that redirection works better.

(2) Modify the apache.conf on ooo-forums VM to do a permanent redirection.

There are probably actions the forum sysadmin needs to take.

The runbooks for both ooo-wiki and ooo-forums need to be checked if they are 
fully up to date. TerryE's falling out with Infra was in part over Infra's 
understandable requirement that the runbooks be quickly consumable by anyone in 
text. He refused and so these are at risk.

Regards,
Dave

> 
> 
> If so that is bad for Google.  It could penalize the forums
>> in search results due to the "duplicate content penalty"  (essentially
>> it looks spammy to have identical content at multiple different
>> URL's).
>> 
>> See:  
>> http://googlewebmastercentral.blogspot.com/2008/09/demystifying-duplicate-content-penalty.html
>> 
>> The preferred way is to either:
>> 
>> 1) Redirect from the old URL to the new URL
>> 
>> or
>> 
>> 2) Use the re="canonical" directive to ;et Google know what the
>> preferred URL is;
>> http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html
>> 
>> 
>>> Could a redirection solve all this problems at once?
>>> 
>>> Regards
>>> Ricardo

Re: Extension downloading problem

[Roberto Galoppini]

On Sun, Aug 26, 2012 at 3:56 AM, Dave Fisher  wrote:

>
> On Aug 25, 2012, at 6:37 PM, Rob Weir wrote:
>
> > On Fri, Aug 24, 2012 at 5:59 PM, Andrea Pescetti 
> wrote:
> >> Dave Fisher wrote:
> >>>
> >>> Has anyone inspected the MIME Type returned? If it is not a proper
> >>> one for OXT then it is possible that IE8 is doing detection of the
> >>> type.
> >>
> >>
> >> I had different results than Dave's, and I concluded I see different
> MIME
> >> types depending on the mirror I get, so this depends on how each
> individual
> >> mirror used by SourceForge is configured.
> >>
> >> Example with repeated attempts (strings are in Italian but it's easy to
> >> understand that the first and last one are right, the other mirrors are
> >> not):
> >>
> >
> > Good work.  I'm copying Roberto on this, since it sounds like this
> > will need a configuration change on the SourceForge side.
> >
> > Also, I wonder if it would be worth submitting a patch for Apache.  It
> > looks like they have the other content types used by OpenOffice, but
> > not oxt files:
> >
> > http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types
>
> That makes sense although it won't help in this case as the mirror is:
>
> Server: nginx/1.0.14
>
> Might need to submit the patch there as well.
>

That extension is hosted by a third party, I'm afraid I couldn't help much
in this case, though.

Roberto


>
> Regards,
> Dave
>
> >
> > -Rob
> >
> >
> >> $ wget
> http://extensions.openoffice.org/e-files/874/29/oracle-pdfimport.oxt
> >> Posizione:
> >>
> http://ignum.dl.sourceforge.net/project/aoo-extensions/874/29/oracle-pdfimport.oxt
> >> [segue]
> >> Lunghezza: 4899523 (4,7M) [application/vnd.openofficeorg.extension]
> >>
> >> $ wget
> http://extensions.openoffice.org/e-files/874/29/oracle-pdfimport.oxt
> >> Posizione:
> >>
> http://garr.dl.sourceforge.net/project/aoo-extensions/874/29/oracle-pdfimport.oxt
> >> [segue]
> >> Lunghezza: 4899523 (4,7M) [application/octet-stream]
> >>
> >> $ wget
> http://extensions.openoffice.org/e-files/874/29/oracle-pdfimport.oxt
> >> Posizione:
> >>
> http://heanet.dl.sourceforge.net/project/aoo-extensions/874/29/oracle-pdfimport.oxt
> >> [segue]
> >> Lunghezza: 4899523 (4,7M) [application/octet-stream]
> >>
> >> $ wget
> http://extensions.openoffice.org/e-files/874/29/oracle-pdfimport.oxt
> >> Posizione:
> >>
> http://dfn.dl.sourceforge.net/project/aoo-extensions/874/29/oracle-pdfimport.oxt
> >> [segue]
> >> Lunghezza: 4899523 (4,7M) [application/octet-stream]
> >>
> >> $ wget
> http://extensions.openoffice.org/e-files/874/29/oracle-pdfimport.oxt
> >> Posizione:
> >>
> http://freefr.dl.sourceforge.net/project/aoo-extensions/874/29/oracle-pdfimport.oxt
> >> [segue]
> >> Lunghezza: 4899523 (4,7M) [application/vnd.openofficeorg.extension]
> >>
> >> MIME types are defined at the web server level, so the configuration for
> >> each mirror is probably responsible for this difference. Then most
> browsers
> >> will get it right nevertheless, but some might be tricked by receiving
> the
> >> generic "octet-stream" type and interpreting it as a valid ZIP file
> (which
> >> is correct, but not the best thing to do of course) before checking if
> it is
> >> a valid OXT file as well.
> >>
> >> A simple test could be to ask people who report problems if they get
> >> different behaviors with
> >>
> http://garr.dl.sourceforge.net/project/aoo-extensions/874/29/oracle-pdfimport.oxt
> >> (which serves OXT as octet/stream) and
> >>
> http://freefr.dl.sourceforge.net/project/aoo-extensions/874/29/oracle-pdfimport.oxt
> >> (which serves OXT as application/vnd.openofficeorg.extension).
> >>
> >> Regards,
> >>  Andrea.
>
>

-- 

This e- mail message is intended only for the named recipient(s) above. It 
may contain confidential and privileged information. If you are not the 
intended recipient you are hereby notified that any dissemination, 
distribution or copying of this e-mail and any attachment(s) is strictly 
prohibited. If you have received this e-mail in error, please immediately 
notify the sender by replying to this e-mail and delete the message and any 
attachment(s) from your system. Thank you.

Re: [WWW]Some trouble with the new URLs for the forums

[Rob Weir]

On Sun, Aug 26, 2012 at 11:03 AM, RGB ES  wrote:
> 2012/8/26 Rob Weir :
>> On Sun, Aug 26, 2012 at 8:31 AM, RGB ES  wrote:
>>> Adding to the (lack of) redirection problem between the old and the
>>> new URL expressed on other threads, there are other problems reported
>>> by users. The first one is that forum notifications still arrive with
>>> only the old URL. Also, there are users experimenting problems with
>>> automatic log-in not working on the new URL.
>>>
>>> Another point that came to my mind is what happens with web crawler
>>> bots registered on the forums: I think that google, yahoo and all the
>>> others are still logging on (and indexing) the old URLs and ignoring
>>> the new ones. In fact, when you perform a web search on google, for
>>> example, about AOO all results that point to the forums show the old
>>> URL...
>>>
>>
>> Are we exposing two different URL's for the forums, with the same
>> content?
>
> Exactly. You can enter the forum from both, the user.service... and
> the forum.openoffice... addresses.
>

There are command line tools that can check this, but also anyone can
put a URL here:

http://www.webconfs.com/redirect-check.php

It is not showing any redirection.


>
>  If so that is bad for Google.  It could penalize the forums
>> in search results due to the "duplicate content penalty"  (essentially
>> it looks spammy to have identical content at multiple different
>> URL's).
>>
>> See:  
>> http://googlewebmastercentral.blogspot.com/2008/09/demystifying-duplicate-content-penalty.html
>>
>> The preferred way is to either:
>>
>> 1) Redirect from the old URL to the new URL
>>
>> or
>>
>> 2) Use the re="canonical" directive to ;et Google know what the
>> preferred URL is;
>> http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html
>>
>>
>>> Could a redirection solve all this problems at once?
>>>
>>> Regards
>>> Ricardo

Re: [WWW]Some trouble with the new URLs for the forums

[RGB ES]

2012/8/26 Rob Weir :
> On Sun, Aug 26, 2012 at 8:31 AM, RGB ES  wrote:
>> Adding to the (lack of) redirection problem between the old and the
>> new URL expressed on other threads, there are other problems reported
>> by users. The first one is that forum notifications still arrive with
>> only the old URL. Also, there are users experimenting problems with
>> automatic log-in not working on the new URL.
>>
>> Another point that came to my mind is what happens with web crawler
>> bots registered on the forums: I think that google, yahoo and all the
>> others are still logging on (and indexing) the old URLs and ignoring
>> the new ones. In fact, when you perform a web search on google, for
>> example, about AOO all results that point to the forums show the old
>> URL...
>>
>
> Are we exposing two different URL's for the forums, with the same
> content?

Exactly. You can enter the forum from both, the user.service... and
the forum.openoffice... addresses.


 If so that is bad for Google.  It could penalize the forums
> in search results due to the "duplicate content penalty"  (essentially
> it looks spammy to have identical content at multiple different
> URL's).
>
> See:  
> http://googlewebmastercentral.blogspot.com/2008/09/demystifying-duplicate-content-penalty.html
>
> The preferred way is to either:
>
> 1) Redirect from the old URL to the new URL
>
> or
>
> 2) Use the re="canonical" directive to ;et Google know what the
> preferred URL is;
> http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html
>
>
>> Could a redirection solve all this problems at once?
>>
>> Regards
>> Ricardo

Re: [WWW]Some trouble with the new URLs for the forums

[Rob Weir]

On Sun, Aug 26, 2012 at 8:31 AM, RGB ES  wrote:
> Adding to the (lack of) redirection problem between the old and the
> new URL expressed on other threads, there are other problems reported
> by users. The first one is that forum notifications still arrive with
> only the old URL. Also, there are users experimenting problems with
> automatic log-in not working on the new URL.
>
> Another point that came to my mind is what happens with web crawler
> bots registered on the forums: I think that google, yahoo and all the
> others are still logging on (and indexing) the old URLs and ignoring
> the new ones. In fact, when you perform a web search on google, for
> example, about AOO all results that point to the forums show the old
> URL...
>

Are we exposing two different URL's for the forums, with the same
content?  If so that is bad for Google.  It could penalize the forums
in search results due to the "duplicate content penalty"  (essentially
it looks spammy to have identical content at multiple different
URL's).

See:  
http://googlewebmastercentral.blogspot.com/2008/09/demystifying-duplicate-content-penalty.html

The preferred way is to either:

1) Redirect from the old URL to the new URL

or

2) Use the re="canonical" directive to ;et Google know what the
preferred URL is;
http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html


> Could a redirection solve all this problems at once?
>
> Regards
> Ricardo

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Rob Weir]

On Sun, Aug 26, 2012 at 7:46 AM, Ross Gardler
 wrote:
> Moving back to AOO lists
>
> These argument is a waste of everyones time. It seems to me that what is/is
> not permissible is clear, indeed has been clear for some time.the summary
> is... Patches welcome.
>

Clear to some, but obviously not clear to others on the IPMC, since
some are suggesting that this podling is not in conformance with ASF
policy with regard to releases.

> More importantly...
>
> As for some members of the AOO PPMC implying this is all new to them
> because it is not documented in precise language is frankly insulting to
> mentors whom have worked hard to communicate release policy around binaries.
>

Ross you should read the entire thread.  You'll find that some on the
IPMC are suggesting that there is more to policy that what you or Joe
think there is.

I'm trying to figure out exactly what that delta is.  If you have
anything constructive to add, I'm sure it would be appreciated.

It is one thing to have an unwritten policy, it is another to have
vastly different interpretations of what that policy is.  For
something as critical as defining what a release is, since there are
clearly differences of opinion, it is probably time to raise it above
the level of folklore, and write it down.  No one should be genuinely
insulted by a request that what is claimed as ASF policy be written
down, especially if someone has already volunteered to do the
drafting.

In any case I now count four people on the IPMC list who are
suggesting that we need a written policy in this area, to remove
ambiguity.

> Individuals arguing against those who know the ASF well, and are supported
> by the vast majority of community commentators (including those opting to
> stay silent because their points have been made), are not demonstrating
> their ability to work in a collaborative, constructive project environment.
>
> When creating a PMC we are looking for people who can resolve conflict, not
> make conflict. PMC members need to be constructive not obstructive. A
> failure to recognise the difference is a demonstration of a failure to
> understand how ASF projects work. PMC membership does not empower people to
> contribute to the code, it empowers them to ensure the community is healthy.
>

IMHO it is very constructive in a disagreement to at least identify,
with some precision, what it is that we are disagreeing about.
Until that occurs, we're just going in circles.  So far I'm the only
one in that thread who has put forward a constructive proposal for
this language, and asked if there was anything to add.

-Rob

> The style of argumentation on this topic is, in some cases, destructive not
> constructive. I'm not replying to a specific mail or individual, I'm simply
> asking people to consider whether sending another email is constructive or
> destructive. Is it possible to put that time into a constructive patch
> instead?
>
> Ross
> On Aug 26, 2012 7:26 AM, "Branko Čibej"  wrote:
>
>> On 26.08.2012 13:15, Tim Williams wrote:
>> > Marvin gave the link earlier in this thread. 4th para is the relevant
>> bit.
>> >
>> > http://www.apache.org/dev/release.html#what
>>
>> The relevant part is in the last paragraph. However, that says
>> "convenience" and defines version numbering requirements, but it does
>> /not/ state that the binaries are not sanctioned by the ASF and are not
>> part of the official ASF release.
>>
>> It would be very useful if that paragraph were amended to say so
>> explicitly. I've had no end of trouble trying to explain to managers and
>> customers that any binaries that come from the ASF are not "official".
>> Regardless of the policy stated numerous times in this thread and on
>> this list, this is not clear anywhere in the bylaws or other online
>> documentation (that I can find).
>>
>> -- Brane
>>
>> P.S.: I asked this same question on legal-discuss a week ago. My post
>> has not even been moderated through as of today, so referring people to
>> that list doesn't appear to be too helpful.
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

Re: CMS diff: Why OpenOffice.org: Public administrations

[Michal Hriň]

Shenfeng,

I published yours latest patches (which you send here 6 days ago).

Thanks.
Michal Hriň


Dňa Mon, 20 Aug 2012 04:18:50 +0200 Rob Weir  napísal:


On Sun, Aug 19, 2012 at 9:58 PM, Shenfeng Liu  wrote:

Rob,
  That's my translations to the existing website materials. So it is no
problem to wait to publish together with our announcement.



When using the CMS a publish operation is "all or nothing".  So if we
publish your changes then we also need to publish any other changes
that are pending on the staging server.  Since we are preparing to
announce the 3.4.1 release we are starting to load
announcement-related changes onto the staging server.  But we're not
ready to publish them yet.

So my note was just to remind other committers that it is OK to commit
your changes and get them onto the staging server, but to wait for
publishing them.

-Rob


- Shenfeng


2012/8/19 Rob Weir 


Let's be careful.  Don't we already have some announcement changes on
staging?  If so we can bring this change as well onto staging, but we
should avoid publishing, since that is all-or-nothing, and we don't
want to put the announcement changes out yet.

-Rob

On Sun, Aug 19, 2012 at 11:28 AM, Shenfeng Liu 
wrote:
> Clone URL (Committers only):
>
https://cms.apache.org/redirect?new=anonymous;action=diff;uri=http://ooo-site.apache.org/zh-cn%2Fwhy%2Fwhy_gov.mdtext
>
> Shenfeng Liu
>
> Index: trunk/content/zh-cn/why/why_gov.mdtext
> ===
> --- trunk/content/zh-cn/why/why_gov.mdtext  (revision 1374681)
> +++ trunk/content/zh-cn/why/why_gov.mdtext  (working copy)
> @@ -1,4 +1,4 @@
> -Title: Why OpenOffice.org: Public administrations
> +Title: 为何选择Apache OpenOffice：公共管理
>  Notice:Licensed to the Apache Software Foundation (ASF) under  
one
> or more contributor license agreements.  See the NOTICE  
file

> distributed with this work for additional information
> @@ -16,20 +16,20 @@
> specific language governing permissions and limitations
> under the License.
>
> -![Why Apache OpenOffice: Public
administrations](/why/images/why_gov.png) # {.rfloatimg}
> +![为何选择Apache OpenOffice：公共管理](/why/images/why_gov.png) #  
{.rfloatimg}

>
> -Public administrations and people working at **all levels of
government** (local / federal / regional / national etc) find Apache
OpenOffice is their ideal software solution. The combination of a
**flexible word processor**, a **powerful spreadsheet**, **dynamic
graphics**, **database access** and more meets all the everyday needs  
of a

typical busy office worker.
>  
+公共管理单位以及为**各级政府机关**工作的人（无论是地方的还是中央的，区域性的还是全国性的）都会发现Apache

OpenOffice是他们理想的软件解决方案。它的组合中包含一个**灵活的文本编辑器**，一个**强大的电子表格**，**灵活的绘图**，**数据库访问**等等，可以满足一个忙碌的办公室工作人员的所有日常办公需求。
>
> -Already available in a **wide range of languages**, OpenOffice can  
be

freely translated by local teams.
> +OpenOffice可以被本地团队自由地翻译，所以拥有**许多不同的语言包**。
>
> -  - **Best value**
> +  - **价值最大化**
>
> -Using Apache OpenOffice demonstrates your commitment to deliver
best value services. It is not owned by any commercial organisation.  
Its
open source licence means there are no licence fees to pay, no  
expensive
annual audits, and no worries about non-compliance with onerous and  
obscure

licencing conditions. You may also distribute the software free to your
employees, through the schools system, or any other channel of your  
choice.

> +使用Apache
OpenOffice可以帮助你实现服务价值最大化的承诺。它不被任何商业组织所拥有。它的开源许可协议意味着没有许可证费，没有昂贵的年审，并且不用担心违反那些繁琐而又模糊不清的许可协议条款。你还可以通过教育系统或任何你选择的途径将这个软件免费分发到你的员工手里。
>
> -  - **Data is safe**
> +  - **数据安全保证**
>
> -Freedom of Information Acts require that the documents you  
create

today will be accessible years in the future. Apache OpenOffice is the
first software in the world to use ISO approved file formats as its
default. It also has the ability to create PDF files if you need to  
publish
information in a standard 'read only' format. If you already have  
(possibly
unlicenced) office software, Apache OpenOffice should be able to read  
your

old files.
> + 
信息自由法案要求你今天所创建的文档在未来几年内都可以被访问。Apache

OpenOffice是世界上第一款使用ISO批准的标准文件格式作为缺省格式的软件。如果你需要通过标准的“只读”格式发布信息，它同样可以创建PDF文件来满足你的要求。如果你已经有了办公软件（也许不是正版的？），Apache
OpenOffice可以读取你的那些旧文件。
>
> -  - ** Open for all**
> +  - **对所有人开放**
>
> -There are no secrets in Apache OpenOffice - our open-source  
policy
means anyone can inspect the code or even help us develop the  
software. We
actively encourage local teams to produce versions for minority  
languages.

OpenOffice is a leading international force in the movement for digital
inclusion - making software of the highest quality available to all,
regardless of income.
> +在Apache
OpenOffice中没有秘密——我们的开源政策意味着任何人都可以查看源代码或者甚至帮助我们开发这个软件。我们积极鼓励本地团队制作少数民族语言的版本。OpenOffice在数字化领域是一个国际化的领导力量——它汇集来源于各方的贡献集，为所有人制作最高质量的软件。
>




--
Táto správa bola vytvorená poštovým klientom v prehliadači Opera:  
http://www.opera.com/mail/

[WWW]Some trouble with the new URLs for the forums

[RGB ES]

Adding to the (lack of) redirection problem between the old and the
new URL expressed on other threads, there are other problems reported
by users. The first one is that forum notifications still arrive with
only the old URL. Also, there are users experimenting problems with
automatic log-in not working on the new URL.

Another point that came to my mind is what happens with web crawler
bots registered on the forums: I think that google, yahoo and all the
others are still logging on (and indexing) the old URLs and ignoring
the new ones. In fact, when you perform a web search on google, for
example, about AOO all results that point to the forums show the old
URL...

Could a redirection solve all this problems at once?

Regards
Ricardo

How to confirm old issues with AOO 3.4.1 ?

[oliver . brinzing]

Hi,

How can I confirm old issues with new versions of AOO?

Background: Some of my issues are more than 10 years old - originally submitted 
with oo 1.0 ;-)
Some of them still exist, others may be fixed without closing the corresponding 
issue.

Btw: I was told not to change the "Version" field.

Could we add a field "last confirmed with AOO", for example?
IMHO this would be more effective than adding a simple comment.

Best Regards
Oliver

[DISCUSS][Linux]Drop distro specific RPMs

[RGB ES]

This time I installed not the "suse" desktop integration RPM but the
"freedesktop" one, and it worked without problems. If someone confirm
that this is the same for fedora and mandriva then I think we can
safely drop those distro specific RPMs and offer only one, like we
offer only one .deb on the debian packages.

What do you think?

Regards
Ricardo

Re: Extension downloading problem

[Andrea Pescetti]

Rob Weir wrote:

Also, I wonder if it would be worth submitting a patch for Apache.  It
looks like they have the other content types used by OpenOffice, but
not oxt files:
http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types


Actually, it seems it's already been there for a while:
$ svn annotate mime.types  | grep oxt
571614   fielding application/vnd.openofficeorg.extension   oxt
$ svn log | grep 571614
r571614 | fielding | 2007-08-31 23:57:29 +0200(ven, 31 ago 2007) | 3 lines

and if I put an extension on my people.apache.org account I see it's 
served correctly (of course, this has nothing to do with the problem 
under discussion; but if problems come from an incorrect MIME type, then 
people reporting the problem should be able to download

http://people.apache.org/~pescetti/tmp/dict-it.oxt
correctly).

Regards,
  Andrea.

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Ross Gardler]

Moving back to AOO lists

These argument is a waste of everyones time. It seems to me that what is/is
not permissible is clear, indeed has been clear for some time.the summary
is... Patches welcome.

More importantly...

As for some members of the AOO PPMC implying this is all new to them
because it is not documented in precise language is frankly insulting to
mentors whom have worked hard to communicate release policy around binaries.

Individuals arguing against those who know the ASF well, and are supported
by the vast majority of community commentators (including those opting to
stay silent because their points have been made), are not demonstrating
their ability to work in a collaborative, constructive project environment.

When creating a PMC we are looking for people who can resolve conflict, not
make conflict. PMC members need to be constructive not obstructive. A
failure to recognise the difference is a demonstration of a failure to
understand how ASF projects work. PMC membership does not empower people to
contribute to the code, it empowers them to ensure the community is healthy.

The style of argumentation on this topic is, in some cases, destructive not
constructive. I'm not replying to a specific mail or individual, I'm simply
asking people to consider whether sending another email is constructive or
destructive. Is it possible to put that time into a constructive patch
instead?

Ross
On Aug 26, 2012 7:26 AM, "Branko Čibej"  wrote:

> On 26.08.2012 13:15, Tim Williams wrote:
> > Marvin gave the link earlier in this thread. 4th para is the relevant
> bit.
> >
> > http://www.apache.org/dev/release.html#what
>
> The relevant part is in the last paragraph. However, that says
> "convenience" and defines version numbering requirements, but it does
> /not/ state that the binaries are not sanctioned by the ASF and are not
> part of the official ASF release.
>
> It would be very useful if that paragraph were amended to say so
> explicitly. I've had no end of trouble trying to explain to managers and
> customers that any binaries that come from the ASF are not "official".
> Regardless of the policy stated numerous times in this thread and on
> this list, this is not clear anywhere in the bylaws or other online
> documentation (that I can find).
>
> -- Brane
>
> P.S.: I asked this same question on legal-discuss a week ago. My post
> has not even been moderated through as of today, so referring people to
> that list doesn't appear to be too helpful.
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>