January 2010 - openSUSE Features - openSUSE Mailing Lists

[openFATE 308801] non interactive osc mode
by fate_noreply＠suse.de 22 Jan '10

22 Jan '10

Feature changed by: Michal Vyskocil (mvyskocil) Feature #308801, revision 7 Title: non interactive osc mode Buildservice: Evaluation Priority Requester: Desirable Projectmanager: Neutral Requested by: Michal Vyskocil (mvyskocil) Developer: Marcus Hüwe (marcus_h) Description: Allow (by an option) osc to be called in a noninterractive mode in which all questions would be replaced by returning a proper exit code and an option to set the missing information noninterractively. The first example in my mind is a username and password prompt. This allows third-party SW to work with BS via osc in much better controlled mode. Discussion: #1: Adrian Schröter (adriansuse) (2010-01-21 12:30:39) hm, osc offers a lib which is intented to be use by third party. Can you use this one ? + #3: Michal Vyskocil (mvyskocil) (2010-01-22 13:01:41) (reply to #1) + A baseline of this request is make osc usable in a traditional unix way + - running osc commands in subprocess. This allows to write an user + scripts in every language withouth needs to have a client library in + every possible language. And it's also more easier to integrate osc to + existing codebase using subprocess and non-interactive mode. #2: Adrian Schröter (adriansuse) (2010-01-22 11:11:12) asking Michal -- openSUSE Feature: https://features.opensuse.org/308801

1 0

[openFATE 308801] non interactive osc mode
by fate_noreply＠suse.de 22 Jan '10

22 Jan '10

Feature changed by: Adrian Schröter (adrianSuSE) Feature #308801, revision 6 Title: non interactive osc mode Buildservice: Evaluation Priority Requester: Desirable Projectmanager: Neutral Requested by: Michal Vyskocil (mvyskocil) Developer: Marcus Hüwe (marcus_h) Description: Allow (by an option) osc to be called in a noninterractive mode in which all questions would be replaced by returning a proper exit code and an option to set the missing information noninterractively. The first example in my mind is a username and password prompt. This allows third-party SW to work with BS via osc in much better controlled mode. Discussion: #1: Adrian Schröter (adriansuse) (2010-01-21 12:30:39) hm, osc offers a lib which is intented to be use by third party. Can you use this one ? + #2: Adrian Schröter (adriansuse) (2010-01-22 11:11:12) + asking Michal -- openSUSE Feature: https://features.opensuse.org/308801

1 0

[openFATE 308801] non interactive osc mode
by fate_noreply＠suse.de 22 Jan '10

22 Jan '10

Feature changed by: Adrian Schröter (adrianSuSE) Feature #308801, revision 5 Title: non interactive osc mode - Buildservice: New + Buildservice: Evaluation Priority Requester: Desirable + Projectmanager: Neutral Requested by: Michal Vyskocil (mvyskocil) + Developer: Marcus Hüwe (marcus_h) Description: Allow (by an option) osc to be called in a noninterractive mode in which all questions would be replaced by returning a proper exit code and an option to set the missing information noninterractively. The first example in my mind is a username and password prompt. This allows third-party SW to work with BS via osc in much better controlled mode. Discussion: #1: Adrian Schröter (adriansuse) (2010-01-21 12:30:39) hm, osc offers a lib which is intented to be use by third party. Can you use this one ? -- openSUSE Feature: https://features.opensuse.org/308801

1 0

[openFATE 308334] Distribute individual letters across cell width and height (aka 均等割符)
by fate_noreply＠suse.de 22 Jan '10

22 Jan '10

Feature changed by: Kohei Yoshida (kohei_yoshida) Feature #308334, revision 27 Title: Distribute individual letters across cell width and height (aka 均等割符) Requested by: Kohei Yoshida (kohei_yoshida) Description: Distribute letters at equal intervals across cell's width such that the first and last letters are aligned with the left and right edge of the cell, respectively. Also support similar distribution mechanism in a vertical direction. This functionality is also known as Kin-tou Wari-fu (均等割符) in Japanese, and is very common operation among Japanese Excel users. Relations: - i#107467 - Excel import issue with cells with distributed content (url: http://qa.openoffice.org/issues/show_bug.cgi?id=107467) - i#107470 - Request for this feature in the upstream IZ (url: http://qa.openoffice.org/issues/show_bug.cgi?id=107470) - i#53373 - Jusitification issue in Draw/Impress for Japanese text. (url: http://qa.openoffice.org/issues/show_bug.cgi?id=53373) - OASIS TC JIRA issue for the file format change proposal (url: http://tools.oasis-open.org/issues/browse/OFFICE-2317) - User-contributed doc on text justification in Japanese text. (url: http://wiki.services.openoffice.org/wiki/User:Foral/Spec/Justification) - i#71067 - RFE: Distributed justification in Draw. (url: http://www.openoffice.org/issues/show_bug.cgi?id=71067) Use Case: Sentences in the Japanese language do not normally break at each word unlike most Western languages. The normal justification functionality is therefore useless for the Japanese users. Instead, they typically justify sentences by adjusting spaces between letters, which is what this requested functionality will provide. Discussion: #3: Kohei Yoshida (kohei_yoshida) (2010-01-05 14:22:02) I've started looking into this. #4: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:36:46) Here is the initial hurdle: Calc uses XSL-FO for all text formatting, and fo:text-align specifies the alignment of a text (I assume for both horizontal and vertical directions). The bad news is that, this attribute does not allow a "distributed" alignment, but in order for us to implement this feature, we need that to allow a distributed alignment. Reference: http://www.w3.org/TR/xsl/#text-align #5: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:45:10) (reply to #4) Well, I guess I could use the "justify" alignment and additional flag to specify how the content is justified. The spec allows user-agent- specific justification algorithm, so it's doable without breaking the standard. #6: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:49:15) (reply to #5) And we could perhaps use the 'text-justify' attribute to specify the justification algorithm. See below: http://www.w3.org/TR/1999/WD-i18n-format-19990910/#a5 #7: Kohei Yoshida (kohei_yoshida) (2010-01-05 17:59:37) (reply to #6) This one is the latest spec of the fore-cited: http://www.w3.org/TR/i18n-format/#text-justify #8: Kohei Yoshida (kohei_yoshida) (2010-01-08 12:39:43) Ok. Here is how I've decided to store this in ODF. For both normal justifiation and distributed justification, the style attribute 'fo:text-align' is saved as 'justify'. Then, for the distributed justification, an additional style attribute 'csstext3:text- justify' gets stored with a value of 'distribute'. For the normal justification, either this value is 'auto', or this attribute won't get stored at all. It took me a while to get to this point since OOo's handling of style attributes and how they are exported to xml are very complex. But I eventually got it to save and load correctly. #9: Kohei Yoshida (kohei_yoshida) (2010-01-11 13:23:40) For alignment in vertical direction, the current ODF uses style: vertical-align attribute which can be either one of: automatic, bottom, middle, top. First, we need to add a new alignment type 'justify' to the style:vertical-align, and use another attribute to specify the justification method. This would be similar to how the horizontal justification is handled. The problem is that we can't reuse the same 'text-justify' attribute name since that would clash with the horizontal justification method attribute. We need a new attribute name for this to avoid such naming clash. The first name that comes to mind is style:vertical-justify , which specifies the same set of values that the csstext3:text-justify supports. Of course, this imlies that to finalize this feature we need to get blessing from the ODF TC, which may not happen in a timely manner. We need to come up with a "solution" for that as well. #10: Kohei Yoshida (kohei_yoshida) (2010-01-11 22:20:20) So, I was wrong in thinking that this would be a very simple task. Not at all... Calculating text / char spacing involves at least 3 modules: sc, svx, and vcl. So, while the text attributes themselves originate from sc, the actual drawing of the text is done by svx and vcl. On the bright side, once we implement this feature, it would be trivial to extend this support to Draw and Impress as well, since those two apps simply re-use the same text rendering code. #11: Kohei Yoshida (kohei_yoshida) (2010-01-12 15:38:08) (reply to #10) Finally found where the text justification code is. Luckily fixing this there will automatically fix it for all of Calc/Impress/Draw for the Japanese text processing. #12: Kohei Yoshida (kohei_yoshida) (2010-01-12 16:01:07) (reply to #11) Just fixed i#53373 (http://qa.openoffice.org/issues/show_bug.cgi?id=53373) by accident. #13: Kohei Yoshida (kohei_yoshida) (2010-01-15 09:14:05) Implementation is nearing to a finish. What remains to be done are: 1) formally propose a file format change to ODF TC. At least file a change proposal to JIRA (TC's bug database). 2) work on the xls and xlsx import and export filters, to support the new text alignments. 3) support distributed justification in Impress and Draw. in order or priority. #14: Kohei Yoshida (kohei_yoshida) (2010-01-15 20:40:03) Drafted a file format change proposal here: http://wiki.oasis-open.org/office/text_distributed_justification . The corresponding JIRA issue is filed here http://tools.oasis-open.org/issues/browse/OFFICE-2317 . + #15: Kohei Yoshida (kohei_yoshida) (2010-01-21 20:18:30) + Some pretty screenshots in my blog post [ + http://kohei.us/2010/01/21/distributed-text-justification/ ]. :-) -- openSUSE Feature: https://features.opensuse.org/308334

1 0

[New: openFATE 308840] performance: concurrent builds ...
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature added by: Michael Meeks (michael_meeks) Feature #308840, revision 1 Title: performance: concurrent builds ... Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: A local osc build should be safe wrt. concurrency, and preferably encourage it. Currently - before I run 'osc build' I have to have a mental check to see "is there a long-running ISO build happening" (eg). because if there is - as I run 'osc build' I will destroy that jail [ with no prompting ], and corrupt my long-running task. Worse - if I am building an ISO, I can't build a simple package to test it: I have to wait until it is finished [ sure there are environment variables you can set - but how lame is that ! ]. Of course - we really need the FUSE optimisation fate#308837# to make this efficient (given similar packages etc.). However - even some safety-features to avoid trashing an existing build would be rather helpful. It should not be necessary to "just have another machine" to run ISO builds. -- openSUSE Feature: https://features.opensuse.org/308840

1 2

[openFATE 308494] Obsolete suseRegister for openSUSE
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature changed by: Jan Engelhardt (jengelh) Feature #308494, revision 4 Title: Obsolete suseRegister for openSUSE openSUSE-11.3: Evaluation Priority Requester: Mandatory Requested by: Andreas Jaeger (a_jaeger) Description: AFAIK we do not need registration at all anymore for openSUSE, let's obsolete it's usage and tools. Discussion: #1: Michael Löffler (michl19) (2010-01-21 12:34:30) I made the feature public so Stefan Werden who's producing the retail box can check if he needs suseRegister or not. But at first glance I don't see use of suseRegister for openSUSE. + #2: Jan Engelhardt (jengelh) (2010-01-22 00:11:49) + Why was it needed in the first place? -- openSUSE Feature: https://features.opensuse.org/308494

1 0

[openFATE 306006] btrfs in openSUSE
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature added by: Marek Stopka (m4r3k) Feature #306006, revision 1, last change by Title: btrfs in openSUSE openSUSE-11.2: Unconfirmed Priority Requester: Important Requested by: Marek Stopka (m4r3k) Description: I think it is time to make btrfs as a part of upcoming openSUSE 11.2, probably with BIG warning but still there should be possibility to use btrfs and even better with some kind of integration in YaST disk module... Fedora is going for btrfs with next release either. -- openSUSE Feature: https://features.opensuse.org/306006

1 12

[openFATE 307914] package maintenance owner handling
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature added by: Adrian Schröter (adrianSuSE) Feature #307914, revision 1 Title: package maintenance owner handling Buildservice: Evaluation Priority Requester: Mandatory Projectmanager: Mandatory Requested by: Dirk Mueller (dirkmueller) Description: We need to support the package maintainer handling for maintenance update via a new mechanism for the following reasons: * internal PDB is not be used anymore for openSUSE 11.2 * We have now the situation that package X may have different maintainers depending on maintained products. Current discussion points to the following needs: * bugowner needs to be set on packages also for released product projects (like openSUSE:11.1). * request mechanism to add or change a bugowner in foreign projects * maintained products/projects list must be requestable (can be hardcoded list in first attempt) * osc command needs to find all projects and package maintainers for a certain package via an api call. Later steps: * define how a maintained package can be set in the projects * support a "osc prepare_maintainance_update $package" call which creates one projects with all affected package versions for a certain package. * SWAMP integration. -- openSUSE Feature: https://features.opensuse.org/307914

1 5

[New: openFATE 308847] performance: improved scheduling
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature added by: Michael Meeks (michael_meeks) Feature #308847, revision 1 Title: performance: improved scheduling Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Description: Currently, the global scheduling of packages appears rather crude. Some annoying things are - just looking at what is 'scheduled' in a single project (eg. Moblin) vs. 'building' - it would be nice to prioritise packages with a larger number of dependencies - at least within that Project. Then - the scheduler can more quickly, get a better overview of what is waiting to be built. Occassionally when we trigger a full re-build, we have bottlenecks that can be as thin as one or two packages; and it is sad to see them competing with some (immensely wide) openSUSE package-set: even though these key packages (which are competing against tens of other openSUSE pkgs), when built might enable ten others to build. Either way - first prioritising by project, to ensure an even balance of building, is perhaps easier than by dependency spread. Of course - perhaps what is there is 'fair' already, but it doesn't (somehow) seem that way; and it is unclear to me that the algorithms have been designed with the use-case of a vast re-build job running constantly in competition to any given task :-) -- openSUSE Feature: https://features.opensuse.org/308847

1 2

[New: openFATE 308842] rcs: meta data ...
by fate_noreply＠suse.de 21 Jan '10

21 Jan '10

Feature added by: Michael Meeks (michael_meeks) Feature #308842, revision 1 Title: rcs: meta data ... Buildservice: New Priority Requester: Mandatory Requested by: Michael Meeks (michael_meeks) Partner organization: openSUSE.org Description: Currently there is a load of meta-data that is not revision controlled. This can cause serious problems - eg. with a tweak to a 'prjconf' (some of which get quite big) - it is possible to have an irreperably broken project - (without scarce expert help). AFAIK there is no way to retrieve old meta-data at all, or see who changed it, or what happened. This applies to package metadata, and particularly the prjconf meta-data. In Moblin we would tend to extract this to a sub-directory and commit it (inside an Image) or somesuch - but it doesn't scale. To have such a key piece of data [ we have spent hours fiddling with prjconfs eg. ] without any revision tracking is highly unfortunate. Business case (Partner benefit): openSUSE.org: Save people time, don't loose critical data. -- openSUSE Feature: https://features.opensuse.org/308842

1 2