Re: Ubuntu -fcf-protection=full breaking code

[Matthias Klose]

On 2/15/21 3:17 AM, Alex Murray wrote:
> Hi Michael,
> 
> For Ubuntu we try and take an approach where we want as much code that
> is compiled for and *on* Ubuntu to try and take advantage of the various
> toolchain hardening options that are available.  This gives end-users
> the most protection with the least amount of work.

Alex, this doesn't match my memory.  Turning on the hardening flags always was a
hack to build packages with hardening flags that ignored flags in their build
system, which are set by the packaging code.

> In some cases however, this can lead to issues as noted in the github
> issue you linked to - not all compiler options will be suitable for all
> codebases etc. However, there are a huge number of codebases which are
> suitable for this kind of feature and automatically benefit from
> this. Also as Ubuntu is used by a huge number of software developers and
> is a platform of choice in CI/CD systems, this then allows many
> codebases to automatically benefit from these default hardening
> features. To make control-flow protection usable in practice, not only
> does the binary need to be compiled with this enabled, but also all
> shared libraries etc. If a user wants to compile a newer version of a
> library, they can then simply do the usual, configure && make && make
> install, and it will get compiled with these CFLAGS as well (whereas
> were this done solely via dpkg-buildflags or similar, only
> binaries/libraries shipped via debs would likely be compiled with this
> feature which would then make it a bit pointless if some libraries have
> it on but others do not).
> 
> So as with all things, there is a balance that needs to be struck
> between the two - the current solution allows this default to be turned
> off via CFLAGS as mentioned at
> https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-fcf-protection if
> needed - but also ensures that as many different packages or bespoke
> codebases will be compiled with this option on (and as such likely then
> ensure it can be used in end-deployments as with any luck all dependent
> libraries get compiled with it on as well).

The current "balance" is to force things into GCC first, and then tending to
ignore or delay any follow-up work.  -fcf-protection and
-fstack-clash-protection don't show up in build logs for package builds, so at
least for package builds, package maintainers don't easily see which hardening
flags are in use.

Software built by other compilers doesn't take "advantage of the various
toolchain hardening options", so I think your claim made in the first paragraph
is at least misleading.  Non-package builds don't see any of these hardening
options, as well as packages ignoring options set in the build environment.
Even packages respecting their build environment don't see -fcf-protection and
-fstack-clash-protection at all.  Users are also happy using these compilers to
work around the Ubuntu GCC settings with the least amount of work.

Matthias

> 
> Thanks,
> Alex
> 
> On Tue, 2021-02-09 at 05:40:40 +1030, michael Bostwick wrote:
> 
>> Any idea why
>> Overriding the default flags to include -fcf-protection=full breaks ipxe,
>> and other tooling not coded to work around it as can be seen on github:
>> https://github.com/ipxe/ipxe/commit/e8393c3728bf7073d033410373ef6781549c7c3e#commitcomment-46894324
>>
>>
>> There is an easier and more straightforward work around (preferred CFLAGS
>> within the package build), why not use that ?
> 
> 


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: "python-is-python2-but-deprecated" and "python-is-python3" don't provide the "python" package

[Matthias Klose]

On 3/23/20 5:36 PM, Daniel Dromboski wrote:
> Just sent this to "ubuntu-devel," but it probably should have been
> posted here instead...
> 
> ---
> 
> Hi,
> 
> At the moment, neither "python-is-python2-but-deprecated" nor
> "python-is-python3" provide the "python" package.

"python-is-python2-but-deprecated" will provide "python (= 2.7.17-1)" for the
20.04 LTS release.  This is done so that upgrades don't get packages removed,
which depend on python.

> I wonder if this is intended behavior, or an oversight?

it's intended.  Before we are uploading a package with the provides, we have to
make sure that no package in the archive uses the unversioned python as a
runtime or a build dependency.  This work is not yet finished.  Help and patches
are appreciated.  Please subscribe me to such bug reports with patches.

Matthias

> In the last update on this [topic] on the [ubuntu-devel] mailing list,
> back in February,
> it was stated that at least "python-is-python2-but-deprecated" would
> provide the "python" package.
> 
>>  - Before release, add a binary package "python-is-python2-but-deprecated"
> package shipping the /usr/bin/python symlink, and providing the python
> package. [...]
> 
> Thanks.
> 
> 
> P.S. When I run `apt info python-is-python2-but-deprecated` I get this
> about dependencies:
> 
> [...]
> Depends: python2
> Breaks: python, python-is-python3
> Replaces: python, python-is-python3
> [...]
> 
> But no "Provides:"...
> 
> And when I run `apt info python-is-python3` I get:
> 
> [...]
> Depends: python3
> Breaks: python, python-is-python2-but-deprecated
> Replaces: python, python-is-python2-but-deprecated
> [...]
> 
> No "Provides:" again.
> 
> (By contrast here is what I get for `apt info wine-development`, which
> "provides" the wine package):
> 
> [...]
> Provides: wine
> Depends: [...]
> Suggests: [...]
> Breaks: [...]
> Replaces: [...]
> [...]
> 
> With neither back-compatible transition package "providing" the
> "python" package, anything package that currently depends on the
> version-neutral "python"  package can't be installed in Focal.
> 


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Proposal: Let's drop i386

[Matthias Klose]

On 13.05.2018 05:00, Henri Sivonen wrote:
> On Thu, May 10, 2018 at 11:25 PM, Thomas Ward  wrote:
>> However, killing i386 support globally could introduce issues, including
>> but not limited to certain upstream softwares having to go away
>> entirely, due to the interdependency or issues with how certain apps
>> work (read; Wine, 32-bit support, 64-bit support being flaky, and
>> Windows apps being general pains in that they work on 32bit but not
>> always on 64-bit).
> 
> If 32-bit x86 support becomes mainly a thing that's run on x86_64
> hardware as a compatibility measure for things like Wine, it would
> make sense to bring the instruction set baseline to the x86_64 level.
> Specifically, it would make sense to compile the 32-bit x86 packages
> with SSE2 unconditionally enabled.
> 
> This would mean dropping support for Pentium Pro and earlier or Athlon
> XP and earlier, but it's pretty sad to leave all that performance on
> the table in order to support the few computers still in use that have
> Pentium Pro or earlier or Athlon XP or earlier.
> 
> As upstream software assumes SSE2 as the baseline, it will be less and
> less a run-time check and compiling software without SSE2 will mean
> shipping it in a damaged form performance-wise.

I disagree, until you provide data how many packages fail to build, at least in
the testsuites, when run without the extra x87 precision bits.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Proposal: Let's drop i386

[Matthias Klose]

On 10.05.2018 00:12, Walter Lapchynski wrote:
> On 2018-05-09 14:54, Oliver Grawert wrote:
>> Am Mittwoch, den 09.05.2018, 16:07 -0400 schrieb Bryan Quigley:
>>> Less and less non-amd64-compatible i386 hardware is available for
>>> consumers to buy today from anything but computer part recycling
>>> centers. 
>> i386 is still very popular in the embedded and industrial world
> 
> From what I know, the vast majority of current devices in these worlds
> are not i386/x86, but more likely arm. 32-bit, yes, but not i386.
> 
>> while i agree that installer images for it should go away since they
>> actually generate noticeable extra work in testing and QA
> 
> As I understood it, that was what this was about.
> 
>> i386 packages in the archive is something we get for free from debian
> 
> Agreed.

I have never seen yours or Olivers name recently fixing i386 and autopkg test
failures.  Should be easily to do for you, it's free, and there's no work 
involved.

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Firefox ESR package is really needed

[Matthias Klose]

It is my understanding that having a Firefox ESR package in Ubuntu,

 - you need to have a distribution agreement with Mozilla.

 - you commit to keep the esr packages up to date, bot in development
   versions, and at least in LTS releases.

 - you use a separate namespace than the firefox packages currently
   found in Ubuntu.

If all preconditions above are met, then we probably can remove the blacklist
entry, but I assume that would be an always-merge package.

Matthias


On 29.09.2017 17:43, Marcos Alano wrote:
> What is the difference between keep the latest release and a ESR
> release? ESR someday was a latest release.
> 
> On Fri, Sep 29, 2017 at 9:40 AM, Olivier Tilloy
>  wrote:
>> On Fri, Sep 29, 2017 at 8:10 AM, Nrbrtx  wrote:
>>> Dear all!
>>>
>>> Do you have any news about packaging Firefox ESR in supported Ubuntu?
>>
>> This has been discussed this week in New York, and the desktop team
>> doesn't have the resources to commit to packaging and maintaining
>> Firefox ESR, unfortunately.
>>
>>
>>> On Sun, Sep 10, 2017 at 12:08 AM, Logan Rosen  wrote:

 Matthias, it looks like you added firefox-esr to the sync blacklist from
 Debian in this commit. Can you please shine some light on why this change
 was made? Thanks!

 On Sat, Sep 9, 2017 at 2:03 PM, Nrbrtx  wrote:
>
> Dear Ubuntu developers!
>
> For enterprise Ubuntu users Firefox ESR is needed.
> It does not change too fast and support old "LEGACY" extensions.
>
> This problem was discussed at least twice on AskUbuntu (see
> https://askubuntu.com/questions/305199/is-there-a-deb-package-to-install-firefox-esr
> and
> https://askubuntu.com/questions/505895/how-can-i-install-an-older-version-of-firefox-in-ubuntu-14-04
> ).
> There is a bug about this problem on Launchpad (see
> https://bugs.launchpad.net/bugs/1676164).
>
> For example in Windows my organization uses Firefox ESR.
> We do not need bells and whistles, we need to do our work with stable
> user experience and without security vulnerabilities.
>
> Debian already has Firefox ESR (see
> https://packages.debian.org/search?suite=all=1=names=firefox-esr)
> for all supported versions.
>
> Please add these packages to all supported Ubuntu versions.
> You may want to use bleeding edge version as default, but please add
> firefox-esr package too.
>
>
> With best regards,
> Norbert.
>
> --
> ubuntu-desktop mailing list
> ubuntu-desk...@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
>

>>>
>>>
>>> --
>>> ubuntu-desktop mailing list
>>> ubuntu-desk...@lists.ubuntu.com
>>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
>>>
>>
>> --
>> ubuntu-desktop mailing list
>> ubuntu-desk...@lists.ubuntu.com
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
> 
> 
> 


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

GCC 7 default update planned for early August

[Matthias Klose]

Hi,

it's this time of the year where you go to your vacation, and look at a new
shiny new GCC version in the archive when you come back.  Well, not exactly ...

I'm planning to change the default on Aug 03/04, and then working to get things
migrated and buildable again, including two transitions for GCC runtime
libraries.  Fixing things pro-actively is appreciated.  If there are questions,
please use the #ubuntu-devel irc channel.  Resources for the GCC 7 update are:

Results of a test rebuild using GCC 7:

  http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20170706-gcc7-artful.html

The ubuntu-toolchain-r/test PPA has the updated defaults packages.

Distro specific informations (and bugs filed for Debian only):

  https://wiki.debian.org/GCC7

Upstream documentation for porting:

  https://gcc.gnu.org/gcc-7/porting_to.html

Thanks for your support for this update!

  Matthias

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Feasibility of Python 2.7 security update in 14.04

[Matthias Klose]

On 24.10.2016 20:02, Aaron Gable wrote:
> Yes, both points are true, which is why I initially asked if this could be
> upgraded as a [security] fix. This is certainly a security upgrade --
> preventing POODLE and actually enforcing SSL validation (which lots of
> folks *think* the're getting, but aren't) are huge wins on the security
> front. And security upgrades are generally not required to be as strictly
> backwards compatible. This change would preserve API compatibility, and
> modify behavior for the better, so I would like to help it move forward.
> What can I do to help resolve the testing difficulties mentioned in
> https://bugs.launchpad.net/ubuntu/+bug/1525507 ?
> 
> Aaron
> 
> On Fri, Oct 21, 2016 at 2:08 AM Ernst Sjöstrand  wrote:
> 
>> Hi,
>>
>> I'm all in favor of updating things like this, however these two have the
>> potential to break some custom scripts out there I think:
>>
>>- HTTPS certificate validation using the system's certificate store is
>>now enabled by default. See PEP 476
>> for details.
>>- SSLv3 has been disabled by default in httplib and its reverse
>>dependencies due to the POODLE attack
>>.
>>
>> Regards
>> //Ernst
>>
>> 2016-10-20 19:28 GMT+02:00 Aaron Gable :
>>
>> Thanks!
>>
>> On Wed, Oct 19, 2016 at 11:38 PM Marc Deslauriers <
>> marc.deslauri...@canonical.com> wrote:
>>
>> Hi,
>>
>> On 2016-10-20 03:32 AM, Aaron Gable wrote:
>>> Hi Ubuntu devs,
>>>
>>> I'd like to inquire about the feasibility of including a update to the
>>> python2.7[1] package in Ubuntu 14.04 LTS Trusty Tahr.
>>>
>>> In particular, the package is currently pinned at Python version
>> 2.7.6[2] (from
>>> November 2.13). However, version 2.7.9[3] (from December 2014) includes
>>> significant network security enhancements[4] that I believe may justify
>> an update.
>>>
>>> Is such an update simply out of the question for an LTS release? If not,
>> who are
>>> the relevant people for me to discuss this in more depth with?
>>>
>>> Thanks for your help,
>>> Aaron
>>>
>>> [1] http://packages.ubuntu.com/trusty/python2.7
>>> [2] https://www.python.org/download/releases/2.7.6/
>>> [3] https://www.python.org/downloads/release/python-279/
>>> [4] https://www.python.org/dev/peps/pep-0466/
>>>
>>>
>>
>> The plan was to update Ubuntu 14.04 to Python 2.7.10. I'm not sure what the
>> current status is:
>>
>> https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1348955
>> https://bugs.launchpad.net/ubuntu/+bug/1525507
>>
>>
>> Is there anything I can do to help these bugs get triaged/prioritized and
>> assigned?
>>
>> +d...@canonical.com
>> Matthias, can you provide additional context on the background and current
>> progress on those bugs?

left a comment in
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1348955


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Multiarch Issue

[Matthias Klose]

On 19.10.2016 02:01, Dylan Taft wrote:
> Hey -
> Apologies for the direct email.
> 
> There are some outstanding bugs filed
> https://bugs.launchpad.net/ubuntu/+source/libxi/+bug/1360342
> 
> http://packages.ubuntu.com/yakkety/i386/libxi-dev/filelist
> http://packages.ubuntu.com/yakkety/amd64/libxi-dev/filelist
> 
> Nothing conflicts in a meaningful way - just headers and man pages
> which would be the same.
> 
> There are only 7 or 8 packages I believe that are affected by
> something like this that are critical for building popular
> applications line Wine.
> 
> If I identify the packages and look through to see that there are no
> actual conflicts, could this be addressed upstream?

Please file bug reports for these, and attach patches, test your changes in a
PPA ensuring that the -dev packages can be co-installed, then subscribe
ubuntu-sponsors.

These are packaging issues, and can't be applied upstream.  Search for existing
Debian issues, and file bug reports for Debian, if there are no bug reports yet.
Link the issues in the bug tracker.

Matthias


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Installation Media and supportability of i386 in 18.04 LTS Re: Ubuntu Desktop on i386

[Matthias Klose]

On 29.06.2016 15:37, Mark Shuttleworth wrote:
> 
> Folks, I think we need to understand whether i386 won't be widely used
> for very small IoT devices and hence be important for developers
> targeting those. I accept i386 i no longer relevant for PC's and
> laptops, but I would not be surprised if 32-bit x86 is used in small
> 'embedded' environments.

isn't x32 targeted for these devices? looks like people do the same in the ARM
universe with aarch64ilp32.


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

please fix build failures, including those introduced by GCC 5

[Matthias Klose]

Hi,

two test rebuilds for vivid are almost finished on all architectures (pending
powerpc and arm64).  It's time to address the build failures seen with these
test rebuilds.  The most important ones are listed in [1] for the vivid
archives.  These really have to be addressed.

In preparation for the w-series (15.10), there was another test rebuild using
GCC 5 (yes, GCC 5 will be the default for 15.10, without any possibility to fall
back to older g++ and gfortran versions).  Some outfall as usual [2].  I think
the switch to GCC 5 will cause a bit more work than the switch to GCC 4.9 in
utopic, so I would like to address as many issues as possible before the switch,
even during the preparation of the 15.04 (vivid) release.  Safe uploads to vivid
would be appreciated.  To check for buildability with GCC 5, add the
ubuntu-toolchain-r/test PPA [3] to your apt sources.  If you have time to kill,
please fix these issues now.  Make sure to forward fixes to the Debian bug
tracker, bugs were filed for a Debian test rebuild as well [4].  Help for
porting issues can be found in the GCC 5 porting notes [5] and an analysis of a
test rebuild for another distro [6].

If you can't, or if you don't want to do an upload, please make sure to file a
launchpad issue, and tag it with 'ftbfs' and probably 'patch', then the issue
will show up in [1] and [2].

Help would be appreciated to fix issues in packages like boost so that we can
get more reliable test rebuild results.

Thanks, Matthias

[1]
http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20150202-vivid.html
[2]
http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20150202-gcc5-vivid.html
[3] https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test
[4]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-5;users=debian-...@lists.debian.org
[5] https://gcc.gnu.org/gcc-5/porting_to.html
[6] https://lists.fedoraproject.org/pipermail/devel/2015-February/207549.html

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Go 1.3 is unmaintained/unsupported upstream

[Matthias Klose]

On 02/13/2015 05:26 PM, John Lenton wrote:
 Go 1.3.3, which we are shipping in Vivid, is unmaintained upstream¹
 (yes, despite being released less than six months ago).
 
 Would it be possible to move to 1.4 in vivid? This wouldn't fix the
 fact that it will become unmaintained in Vivid's timeframe, but at
 least we can get the bugs we find during development fixed upstream.

just use gccgo everywhere, which is go 1.4.


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Fix Blender package?

[Matthias Klose]

Am 19.01.2014 21:16, schrieb Sam Bull:
 Is there any chance we can get a fixed version of Blender available 
 sometime soon? The Ubuntu package is missing Collada support for some 
 reason, and according to the bug report has been for some time now. 
 https://bugs.launchpad.net/ubuntu/+source/blender/+bug/1058777?comments=all

  We're trying to use Ubuntu to develop games, but it's a bit of a barrier 
 if we can't export our models for use in the game without needing to 
 manually install it from the website on everybody's machine.

This is not bad packaging but a library which is not yet packaged. The best
thing is to provide a source package packaging this library.  So please
package the collada library.


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Saucy now open for development

[Matthias Klose]

Saucy is now open for development, with syncs from unstable currently running.
The development version starts with updated versions of GCC and boost.

 - GCC 4.8 is now the default compiler, introducing among other things
   improved C++11 support, AddressSanitizer , a fast memory error detector,
   and ThreadSanitizer, a tool do detect data races.
   Find the complete list of changes at [1].

   Information on porting to GCC 4.8 from previous versions of GCC
   can be found in the porting guide [2].

   The cross compilers for armhf, arm64 and powerpc default to 4.8 as well.

 - Glibc and binutils updates will follow later during this cycle.

 - boost was updated from v1.49 to v1.53.

Please check your uploads in a saucy chroot, don't just test in a raring
environment. See [3] how to setup such a development chroot.

[1] http://gcc.gnu.org/gcc-4.8/changes.html
[2] http://gcc.gnu.org/gcc-4.8/porting_to.html
[3] https://wiki.ubuntu.com/DebootstrapChroot

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: PIE on 64bit

[Matthias Klose]

Am 18.04.2013 20:25, schrieb John Moser:
 Meant to go to list
 On Apr 18, 2013 2:15 PM, John Moser john.r.mo...@gmail.com wrote:
 

 On Apr 18, 2013 2:07 PM, Insanity Bit colintre...@gmail.com wrote:

 On 64bit multiple services (pulseaudio, rsyslogd, many others) are
 shipping without Position Independent Code. On 32bit there is a potential
 performance hit for startup time... but there shouldn't be any performance
 hit (or negligible) on 64bit.


 There is a continuous performance hit of under 1% without
 -fomit-frame-pointer and under 6% with -fomit-frame-pointer on IA-32.  The
 impact is statistically insignificant (i got 0.002% +/- 0.5%) on x86-64.

 The performance hit on IA-32 only applies to main executable code because
 library code is PIC already.  This accounts for under 2% runtime, except in
 X where it used to be 5%.  That makes the overall impact 2% of 6% or
 0.12%--which is non-existent if your CPU is ever at less than 99.88% load
 because you would swiftly catch up.

 In other words:  there is NO PERFORMANCE HIT for PIE in any
 non-laboratory, non-theoretical situation.  (Theo de Raadt argued this with
 me once, using the term very expensive a lot.  I built two identical
 Gentoo boxes and profiled them both extensively with oprofile.  It is
 exactly a theoretical cost, and the performance concerns come from people
 who have no clue what the execution flow of modern software looks like)

I'm tired to repeat that there *is* a performance penalty.  Building the python
interpreters with -fPIE results in about 15% slower benchmarks.  Building GCC
with -fPIE slows down the build times by 10-20%.

So maybe you want to have a python interpreter with -fPIE, accepting this
performance penalty, and gaining some security?  But what else do you gain by
building GCC with -fPIE besides forcing longer build times on developers?

I don't think that -fPIE is ready to be enabled by default, but maybe we need to
think about a better or easier way to enable it. However the current method
using the hardening-wrapper seems to work fine.

  Matthias


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: arm-linux-gnueabi-gcc-4.4 -march=armv4t silently produces armv7 (pkgversion=Ubuntu/Linaro 4.4.5-15ubuntu1)

[Matthias Klose]

On 11/08/2011 10:41 AM, Steffen Dettmer wrote:
 Hi,
 
 I hope I ask on the right place, otherwise a redirection is appreciated.
 I write here because dpkg-query -p gcc-4.4-arm-linux-gnueabi tells:
 Maintainer: Ubuntu Core developers ubuntu-devel-discuss@lists.ubuntu.com.
 On debian-arm mailinglist I learnt it could be a ubuntu-specific
 problem with the compiler package, because arm-linux-gnueabi-gcc-4.4
 (gcc-4.4 4.4.6-11) seems to work correctly.
 
 I have to put two excuses at the begin: first, I'm not a Debian
 or Ubuntu user and not familiar with the dpkg and apt-get
 details; second, I also don't have much knowledge about
 ARM-linux. But I'm learning.
 
 I installed 6.0.1 (according to /etc/debian_version) on an ARM board
 with v5TE architecture which is not able to execute armv7 code.
 Precompiled binaries are v4T. Now I tried to install gcc toolchain to
 build my application. On a squeeze/sid (according to
 /etc/debian_version) intel machine I used synaptic to install packages
 with arm, gnueabi and armel based on guessing inspired by
 reading http://wiki.debian.org/ArmEabiPort. That documentation for me
 unfortunately is insufficient.
 
 I tried to compile with arm-linux-gnueabi-gcc-4.4 -march=armv4t, but
 I do not get Tag_CPU_arch: v4T (readelf -A) but Tag_CPU_arch: v7.
 It seems that the tool chain was built incorrectly and specific to
 armv7; I don't find the multi-libs -- there seems to be only one
 single set of libs (libgcc.a etc)! I had expected one set for each
 combination of compiler flags (hardfloat/softfloat, arm/thumb, ),
 so heaps of libs. I need something in between v4T, thumb, soft-float
 to maybe v5T, armmode, soft-float, interwork.
 
 I considered to rebuilt the packages
 (gcc-4.4-arm-linux-gnueabi_4.4.5-15ubuntu1_i386.deb, others) but I
 have no clue how to do so. The build system seems to be sophisticated.

it is.

the target currently is set in debian/rules2 according to the value of the
`distribution' macro.  I assume you derive from Ubuntu and you get the default
armv7 configuration.

  Matthias

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: More LiveCD space optimizations

[Matthias Klose]

[ compression related discussion removed ]

So maybe we can save some MB with better compression, but we can save more by 
not including files at all.  Of course this requires inspection of the packages 
included on the liveCD.  In the past we did identify some issues and did add 
some diagnostics to the live CD build logs [1].  Of course you can't run 
anything and lengthen the live CD build, but some additional diagnostics maybe 
could be run.

In the past we did see wasted space:

  - Packages which should not be on the CD.  Some things should not be
on the CD at all.  Looking at the current live CD log, a typical
candidate for this would be tcl8.4. Why is it there, and how can
it be avoided?

  - Large doc directories.  If a package becomes too large, maybe it is
worth to split a package into foo and foo-doc, and not ship foo-doc
on the CD (yes there are other ideas not to ship doc dirs at all).
See python-couchdb for an example. The API documentation does not
need to be on the live CD.  The same may be true for other python
packages.

  - Localized help images. You cannot just remove the images from an
application's help, but in the past we did ship all these localized
help images on the CD. CC'ing Martin, don't know the current status.
However it looks like there are some xml files which maybe should
be part of the language packs.

  - Duplicate files. While this is not that important on the live CD,
it's important for the alternate CDs.  Looking at the list of
duplicate files, I see a lot of potential in:

- all the mono packages and libraries

- broken build systems shipping doc files in every binary package.
  see the upstream changelog.gz files (e.g. gnome and OOo).

- firefox and xulrunner shipping duplicate .js files

- package specific stuff (libc6-dev having some identical libs
  in /usr/lib/xen).

- you may see and find more if you are familiar with a particular package.

There is potential in saving space with better compression, but IMO you can 
even 
save more with closely looking what goes on the CD (where we currently don't do 
a good job). The good thing is that both approaches don't exclude each other.

   Matthias

[1] 
http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/ubuntu/latest/livecd-20101007-i386.out

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: More LiveCD space optimizations

[Matthias Klose]

On 07.10.2010 18:07, John McCabe-Dansted wrote:

 That's an interesting optimisation; I didn't really know about it
 either. However, I did use 7zip's Deflate compressor to recompress a
 .zip file of OpenOffice.org's from 5.9 MB to 5.4 MB. The method was
 rather crude, but it did the job:

 mkdir extracted
 cd extracted
 unzip ../file.zip
 7z a -tzip -mx=9 -mfb=258 file.repack.zip extracted/*
 rm -r extracted

 You mean images_human.zip? I have a hunch that compressing that file
 wouldn't actually save space on the liveCD as I can gzip it down to
 3.9MB. It may be better to leave it as an uncompressed zip, and let
 squashfs deal with it. Recompressing the pngs contained in the zip
 sounds worthwhile though. Strangely, even running advzip -z -0
 images_human.zip shrinks it by 3%, and even shrinks the corresponding
 images_human.zip.gz file

 Also, there are 12MB of jar files, which are basically zip files. We
 can also shrink those by 5MB or so with advzip, but that doesn't seem
 to shrink a .tgz of them so it may not shrink the liveCD. Since zip
 files compress file by file, we may be able to save space on the
 liveCD by running advzip -z -0 on them. That would expand them to
 24MB, but reduces the size of a .tgz of them to 4.6MB, possibly saving
 space on the liveCD if squashfs is similarly efficient.

how does OOo behave with the repacked zip file? is it faster, slower, does it 
need more memory when it runs?  imo, changes like this should be integrated 
into 
the package build process, and sent upstream. patches welcome.

same for jar files. are these extracted as fast as without your changes by the 
jvm? if not, then these should be left alone (and afaik there shouldn't be any 
jar files on the live CD).

   Matthias

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Bug#541842: libcloog-ppl-dev: Missing development headers

[Matthias Klose]

On 18.08.2009 19:06, John David Anglin wrote:
 seen as well in the gcc-snapshot build. Looks like the configure test doesn't
 pass -DCLOOG_PPL_BACKEND for the cloog version check.

 When I built and installed libcloog on hpux11.11, an additional
 header was installed that defined CLOOG_PPL_BACKEND.

which one? At least the header which is included by GCC doesn't define this 
macro and the configury seems to take care of this, if the configure option is 
used. See the thread starting at http://gcc.gnu.org/ml/gcc/2009-08/msg00296.html



-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Bug#541842: libcloog-ppl-dev: Missing development headers

[Matthias Klose]

On 19.08.2009 16:03, John David Anglin wrote:
 When I built and installed libcloog on hpux11.11, an additional
 header was installed that defined CLOOG_PPL_BACKEND.

 which one? At least the header which is included by GCC doesn't define this

 /* include/cloog/cloog-config.h.  Generated by configure.  */
 /* include/cloog/cloog-config.h.in.  Generated from configure.in by 
 autoheader.  */

 * Use the PPL backend */
 #define CLOOG_PPL_BACKEND 1
 ...

hmm, the Debian package doesn't build this file. We have sources with an 
cloog.h.in, which reads:

#ifndef CLOOG_H
#define CLOOG_H

#ifdef CLOOG_PPL_BACKEND
# define GNUMP
# includecloog/ppl_backend.h
#else
# include polylib/@cl_cv_poly...@.h
# includecloog/polylib_backend.h
#endif
[...]

 The header cloog.h included it as follows:

 #ifndef CLOOG_H
 #define CLOOG_H
 #include cloog-config.h
 #ifdef CLOOG_PPL_BACKEND
 ...

 macro and the configury seems to take care of this, if the configure option 
 is
 used. See the thread starting at 
 http://gcc.gnu.org/ml/gcc/2009-08/msg00296.html

 It may be that defining CLOOG_PPL_BACKEND in the configure machinary
 is sufficient, but that's not clear as the define may affect the way
 cloog was built.

 Dave




-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: OpenOffice 3 and Firefox 3.1 in Intrepid?

[Matthias Klose]

Vishal Rao schrieb:
 What about other packages like Eclipse (which currently shows at 3.2)

did you package 3.4? very cool! where can I find the package?

  Matthias

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: LLVM 2.2

[Matthias Klose]

Ioannis Nousias schrieb:
 is there any chance in seeing LLVM 2.2 version in Hardy (released in 
 February)? Current version is 1.8, which I think is from Q4 2006!

Yes, if you do follow our documented procedures.

https://wiki.ubuntu.com/SyncRequestProcess

 A request to update the LLVM version has been in launchpad for some time 
 now:
 https://bugs.launchpad.net/ubuntu/+source/llvm/+bug/136495

Please update this bug report accordingly

  Matthias

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Introducing distro-{jre,jre-headless,jdk,jdk-builddep} packages

[Matthias Klose]

[sent to [EMAIL PROTECTED] and [EMAIL PROTECTED]

For packaging we currently use a build dependency on a package which
we did agree for packaging (java-gcj-compat-dev).  Now with other more
conformant Java implementations available, we might want to change to
those implementations for building the packages in the archive.  It
looks like we won't have stuff like OpenJDK and IcedTea available for
all architectures, but might be able to replace some parts with
alternate implementations, e.g. replacing the VM with cacao for some
architectures.  This will result in different package names for
different architectures.  Therefore I'd like to introduce dependency
packages which can be used / referenced across platforms.  The
packages itself are empty except for distro-jre-headless which
contains a symbolic link

  /usr/lib/jvm/distro-java - java-gcj

These packages itself don't hold any other binaries and/or links to
the referenced packages.  We might need to discuss what we minimally
expect from a package claiming to provide a certain version of a
runtime.  The upstream version of these packages corresponds to the
provided runtime (use 1.5 or 5)?  These packages are proposed to be
built from the java-common package.

Comments?

  Matthias

=== ../distro-jre_1.5-28_i386.deb ===
 new debian package, version 2.0.
 size 4032 bytes: control archive= 523 bytes.
 533 bytes,14 lines  control
  72 bytes, 1 lines  md5sums
 Package: distro-jre
 Source: java-common (0.28)
 Version: 1.5-28
 Architecture: i386
 Maintainer: Debian Java Mailing List [EMAIL PROTECTED]
 Installed-Size: 28
 Depends: distro-jre-headless (= 1.5-28), java-gcj-compat (= 1.0.77-4)
 Provides: java-runtime, java2-runtime, java5-runtime
 Section: interpreters
 Priority: optional
 Description: Standard Java or Java compatible Runtime
  This package points to the Java runtime, or Java compatible
  runtime recommended for the i386 architecture,
  which is java-gcj-compat-dev for .

=== ../distro-jre-headless_1.5-28_i386.deb ===
 new debian package, version 2.0.
 size 4170 bytes: control archive= 587 bytes.
 696 bytes,18 lines  control
  81 bytes, 1 lines  md5sums
 Package: distro-jre-headless
 Source: java-common (0.28)
 Version: 1.5-28
 Architecture: i386
 Maintainer: Debian Java Mailing List [EMAIL PROTECTED]
 Installed-Size: 36
 Depends: java-common, java-gcj-compat-headless (= 1.0.77-4)
 Suggests: distro-jre
 Provides: java-runtime-headless, java2-runtime-headless, java5-runtime-headless
 Section: interpreters
 Priority: optional
 Description: Standard Java or Java compatible Runtime (headless)
  This package points to the Java runtime, or Java compatible
  runtime recommended for this architecture, which is
  java-gcj-compat-headless for i386.
  .
  The package is used as dependency for packages not needing a
  graphical display during runtime.

=== ../distro-jdk_1.5-28_i386.deb ===
 new debian package, version 2.0.
 size 4028 bytes: control archive= 523 bytes.
 525 bytes,14 lines  control
  72 bytes, 1 lines  md5sums
 Package: distro-jdk
 Source: java-common (0.28)
 Version: 1.5-28
 Architecture: i386
 Maintainer: Debian Java Mailing List [EMAIL PROTECTED]
 Installed-Size: 28
 Depends: distro-jre (= 1.5-28), java-gcj-compat-dev (= 1.0.77-4)
 Provides: java-sdk, java2-sdk, java5-sdk
 Section: devel
 Priority: optional
 Description: Standard Java or Java compatible Development Kit
  This package points to the Java runtime, or Java compatible
  development kit recommended for this architecture, which is
  java-gcj-compat-dev for i386.

=== ../distro-jdk-builddep_1.5-28_i386.deb ===
 new debian package, version 2.0.
 size 3994 bytes: control archive= 477 bytes.
 432 bytes,12 lines  control
  81 bytes, 1 lines  md5sums
 Package: distro-jdk-builddep
 Source: java-common (0.28)
 Version: 1.5-28
 Architecture: i386
 Maintainer: Debian Java Mailing List [EMAIL PROTECTED]
 Installed-Size: 28
 Depends: distro-jdk (= 1.5-28)
 Section: devel
 Priority: optional
 Description: Standard Java or Java compatible build dependencies
  This package points to the build dependencies used to build
  packages requiring a Java or Java compatible Development Kit.


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Strawman: merge main and universe

[Matthias Klose]

Scott James Remnant schrieb:
 I'd like to make a strawman proposal to be torn apart and burnt as
 necessary: merge main and universe.  I will try and explain my
 rationale, and my alternate proposal.

+1

We apparently have difficulties to communicate that this separation was done
only for the support case mentioned. two examples for universe not being 
ubuntu:

 - distrowatch.com treats universe as non-existant (I contacted them, but
   they didn't want to change their mind).

 - Fedora did get good feedback by integrating extras into core; while
   not directly comparable you can see the some impact on integrating the
   community.

Matthias



-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

IcedTea - a first step towards OpenJDK

[Matthias Klose]

IcedTea is a temporary fork of OpenJDK which allows building with a free
toolchain and adding/replacing code which is not yet available under a free
license. First deb Packages for amd64, i386 and lpia are available at

  deb http://people.ubuntu.com/~doko/ubuntu/ gutsy/
  deb-src http://people.ubuntu.com/~doko/ubuntu/ gutsy/

These packages target developers only. Feedback about the following topics is
appreciated (on ubuntu-devel-discuss or #ubuntu-java):

 - packaging and installation issues; the packaging is derived from the
   sun-javaX packages, so the packages do have the same features and
   bugs.

 - license issues; we currently cannot upload the packages, because some
   files still have non-free or no licenses. Unfortunately there doesn't
   exist yet a list of problematic files.

 - usability; do packages and applications build and run with the new
   jre and jdk (focus on main)?

Please contact me if you do want to join the packaging and maintainance effort.
Thanks for any input.

  Matthias

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: All-sides Testing Report of Ubuntu-7.04 from BSTQC

[Matthias Klose]

konghao schrieb:
 Release of All-sides Testing Report of Ubuntu-7.04

Is this pure 7.04, or are updates taken from the ubuntu-security and/or
ubuntu-updates repositories?

 As a member of Ubuntu community , BSTQC would contribute all the resource we 
 have.

It looks like the reports are generated automatically; is there a chance that
you submit these bug reports to launchpad? malone can accept bug reports by
email, so it should be possible if you can extract that information. It would
ease fixing the bugs you found.

thanks, Matthias

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

cbe toolchain packages for Ubuntu

[Matthias Klose]

[ Please ignore this email, if you do not want to develop for the processor
found in the Sony Playstation 3, or other CBE based systems ]

Experimental ppu/spu toolchain packages for Ubuntu are available for the feisty
and gutsy (development) releases.

 - The packages for the gutsy release can be found in the gutsy archive
   in the `universe' section of the archive.

 - Packages for the feisty release can be found at

 deb http://people.ubuntu.com/~doko/ubuntu feisty-proposed/
 deb-src http://people.ubuntu.com/~doko/ubuntu feisty-proposed/

Both sets of packages are based on the rpm packages found at
http://www.bsc.es/plantillaH.php?cat_id=304 . All packaging bugs not found in
the rpm packages are mine. The naming of the binary packages is the same as
found in the rpm packaging (with libspe{,-dev} renamed to libspe1{,-dev} to
conform with ubuntu and debian policy).

An overview of bugs reported for the packages in ubuntu can be found at
https://bugs.launchpad.net/~ubuntu-cbe/+packagebugs .

I would be pleased to get feedback about the packages either as bug reports in
launchpad, or on an appropriate mailing list (if cbe-oss-dev is inappropriate,
please use ubuntu-devel-discuss@lists.ubuntu.com).

  Matthias

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: libgimme and libwps

[Matthias Klose]

Matt Zimmerman schrieb:
 On Sat, Mar 24, 2007 at 02:15:31AM -0600, Conrad Knauer wrote:
 Also, for a little while libwps (very useful for those of us with old
 word processing docs locked away in that format) was a dependency of
 openoffice.org but its not anymore... what changed with that?
 
 The changelog doesn't have an answer for this one.  It was changed recently
 to use the system copy of this library rather than one included in the
 source tree; perhaps that change was inadvertently reverted?

mistakenly built with the internal libwps copy, already fixed for the next 
upload.


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Google SOC, Project Proposal

[Matthias Klose]

Please could you write down the project idea in a wiki page at wiki.ubuntu.com?
Use the SpecTemplate for the page. If you didn't already apply (see [1]), then
please do so before Mar 26. Evaluation and ranking of the submitted projects
will start next week.

  Matthias

[1] https://wiki.ubuntu.com/GoogleSoC2007/Students

Dan Harvey schrieb:
 Hi
 
 Just though I should introduce myself to the Ubuntu developers mailing
 list and let you rip my idea proposal apart!
 
 I'm Dan Harvey a Natural Science student at Durham Uni (UK) doing
 computer science and am very keen to help out improving the usability
 of the Ubuntu desktop.
 
 The idea I propose links in with two other ideas proposed on the
 Ubuntu GSOC wiki for Integrated web sharing and Easy file sharing
 and synchronization (minus the sync which is a whole different
 problem in itself...). Basically it involves creating a DBus interface
 for file transfer/sharing allowing a unified desktop GUI to access
 different file transfer services to either publish files to share or
 download. This hides the user from any protocol or service differences
 and just lets then do what they want with there data. I'll add a bit
 more detail with a few use cases.
 
 Say Fred wants to share a file with a few friends but its too large to
 e-mail. So the GUI picks behind the scenes that the web server is best
 so asks the http service (could be new daemon or modified Apache or
 lighter) to host a file and make sure ports are opened for it, then
 returns a url for Fred to give to his friends. All the app has to do
 (be it nautilus, f-spot, banshee) is ask for the file to be hosted and
 the http service does the rest.
 
 Freds friend then comes along and finds the link to download, as he's
 using Ubuntu the transfer service for him decided to pick the http
 service to download it and he's happy.
 
 Next is Chris who has recorded a new song with his band (we need a
 gnome based garage band replacement!) and wants to spread it to all
 his friends, and their friends as its an amazing song. So he goes
 though the common GUI which picks (based on its size and who he's
 sending it to) that bit torrent would be the best solution. So this
 App asks the bit torrent service to publish his song, which in turn
 asks the http service to host the torrent file and song to seed it
 which he can in turn send to a friend for them to download.
 
 Chris's friend also happens to be using Ubuntu (or other gnome based
 OS) and find this link to download, the transfer service now works in
 reverse again and picks the bit torrent service to download it with.
 He gets the song and is happy as well!
 
 The reason to have a single DBus interface for the different services
 means the user never know which protocol is used for either sharing or
 receiving so are provided with a consistent user interface. This can
 extend to many different protocols in many different applications and
 many different user cases making it quite simple but very powerful.
 
 Sorry for such a long first message but I want to post the idea here
 so I can get some feed back on it. Will this be useful for people? is
 this a good way to solve this problem? do you see any large flaws in
 it?
 
 Thanks for your time,
 Dan
 


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Tablet PC and Summer of Code

[Matthias Klose]

Charlotte Curtis schrieb:
 I have used onboard, and it seems to work quite well.  In addition to the
 features you have mentioned (popping up as necessary and word prediction) I
 can think of a few other additions, such as a number pad, additional
 language/keyboard configurations, and maybe shortcut keys for commonly used
 text such as passwords.
 
 Aside from the keyboard, what about the calibration issue and general pen
 behaviour?  I have the screen rotation working fairly well with a simple
 script, but the pen is not perfectly calibrated when change between
 portrait
 and landscape.  Also, the buttons on the pen (right click and eraser) do
 not
 behave as they should.  It would be great to have some sort of
 configuration
 tool to take care of these things.
 
 Thanks for all your comments, it's a big help.
 
 Charlotte

Please could you write down the project idea in a wiki page at wiki.ubuntu.com?
Use the SpecTemplate for the page. If you didn't already apply (see [1]), then
please do so before Mar 26. Evaluation and ranking of the submitted projects
will start next week.

  Matthias

[1] https://wiki.ubuntu.com/GoogleSoC2007/Students

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Looking for mentor for Google SoC idea - application start prefetching

[Matthias Klose]

Krzysztof Lichota schrieb:
 I am looking for mentor in Ubuntu team for my Google Summer of Code idea
 - Automatic boot and application start file prefetching.
 
 Abstract:
 I would like to concentrate on delivering prefetching solution for
 everyday use by casual users, leveraging prior solutions where
 appropriate and providing missing parts of complete and automatic
 prefetching:
 
 - Hook into application startup for analysis and prefetching.
 - Add lightweight tracing solution for booting and application startup.
 - Add offline tool to change layout of files on disk for faster prefetching.
 - Add prefetching of filesystem metadata.
 
 Implementation will be concentrated on most important parts (subject to
 analysis of benefit and implementation complexity) with the main goal to
 deliver working automatic solution at the end of project, leaving less
 obvious benefits as secondary goals. Filesystem specific parts will be
 done for ext3 as default file system in Ubuntu and most often used for
 desktops.
 
 Full text of application:
 http://www.mimuw.edu.pl/~lichota/soc2007-prefetch/application.html

Please could you write down the project idea in a wiki page at wiki.ubuntu.com?
Use the SpecTemplate for the page. If you didn't already apply (see [1]), then
please do so before Mar 26. Evaluation and ranking of the submitted projects
will start next week.

  Matthias

[1] https://wiki.ubuntu.com/GoogleSoC2007/Students

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: OpenOffice.org 2.2 release candidate 2 available for testing

[Matthias Klose]

Pavel Rojtberg schrieb:
 Matthias Klose schrieb:
 Pavel Rojtberg schrieb:
 my point with the icons was:
 can we have the tango-icons from the jimmac tango branch?
 No, not in its current form as a replacement for the well tested
 industrial_theme. In its current form its a fork of the industrial icon
 set, which I do not want to maintain separately. If we want to include
 the icons in some way:

  - rename the icon set
  - send a patch to accept the new icon set as an alternative, which
is turned off by default.
  - document the changes compared to the industrial icon set; the
README inside the zip file is very vague, who did change what and
which icons come from which source. IMO in this form it is not
redistributable in main or universe. To address this, add
a ChangeLog, mentioning the copyright and changes per file.

 If you want to submit changes to the existing industrial icon set,
 please send me email for the upstream contacts.

   Matthias
 
 which zip are you referring to? I was talking about:
 cvs -d :pserver:[EMAIL PROTECTED]:/cvs co -r
 cws_src680_jimmactango2 ooo_custom_images
 
 then overwriting the contents of the current images_industrial.zip with
 the tango images and re-zipping it.
 (as suggested by jimmac in his blog:
 http://jimmac.musichall.cz/weblog.php/2007/Feb/19)
 
 this way you dont lose any images and the differences should be also
 clear. I also assumed that stuff from oo.org cvs has no licensing problems.
 
 but I have no I idea how to install the tango icons w/o overwriting
 industrial.

I did have a look at this icon set, and compared to the ones offered in 
   #42061 by Munchkinguy, these look much more complete. Comparing the 
tango and human icon sets, there are 1800 differing files, and 680 files 
missing from the human them.

you can find these differences at http://people.ubuntu.com/~doko/ooicons/

   Matthias

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Java obviously not working

[Matthias Klose]

Markus Hitter schrieb:
 To get some use out of this installation, I'd like to install  
 OpenCascade. While being open source, it comes with a java based  
 installer. Unfortunately, running Java doesn't look that well:
 
 /tmp/isijp053E/bin/i386/native_threads/java: error while loading  
 shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object  
 file: No such file or directory
 
 Indeed, there ist no such file in /usr/lib; the newest one there  
 is ...libc6.0.8 Worse, Adept/Synaptic don't indicate anything  
 about such a library, the libc6.0.8-based version appears to be the  
 newest one.
 
 So my questions are:
 
 - This is a dependency mismatch between java (= gij-4.1) and what's  
 available in feisty's repositories, right?

no.

 - How would I debug (testsuite?) and resolve (compiling some even  
 more recent package?) it?

please ask the distributor of the OpenCascade software first, then you 
may search for that file:

http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=libstdc%2B%2B-libcsearchmode=searchwordcase=insensitiveversion=wartyarch=i386

it's not there. IIRC that one was built by g++-2.95 on system with an 
older glibc. google for libstdc++-libc6.1-1.so.2, find the file or 
informations how to build it.

an alternative might be to modify the installation scripts of your 
software to use a more recent java version.

 - Should I file a bug about such issues?

no.


-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss