Re: Ubuntu Desktop on i386
On 01.02.2016 23:14, Dimitri John Ledkov wrote: > Hello, > > Ubuntu has an i386 port which is fully supported. > > There a bunch of 3rd party applications that rely on the Multi-Arch > technology to support/use i386 binaries on amd64 (e.g. Skype from the > partner archive). BTW, can we ask Microsoft to publish native amd64 > binaries, rather than those that rely on multi-arch i386? Also, does > Valve Steam product rely on i386 multiarch binaries? or is it fully > amd64? (and e.g. downloads/bundles/ships any required i386 binaries > that it needs)? And Netflix - does that run on amd64-only without i386 > multiarch? > > However, it seems to me that this is done specifically on otherwise > full amd64 installations. > > My guess is that: all currently shipped hardware, with enough support > to run full Unity (7) Desktop, is amd64. Tested with amd64 kernel, and > amd64 graphics drivers. And hardware validation is done on amd64 too. > > In 2016, people with i386-only hardware are unlikely to be capable to > run Unity 7 Desktop, and probably run other Ubuntu variants. I guess > there are some accidental i386 users, e.g. those that have installed > i386 variant on amd64 hardware. Just wondering whether you considered netbooks here. Not that old (maybe 6y?) and at least the two specimens I would have around are early Atoms (i386 only) but with (also early) i915 Intel graphics. They used to be reasonably accelerated to cope. Not sure about unity 7. But maybe some reason to allow at least for 16.04 some i386 iso (by 18.04 the problem might be resolved through the crappy life-span recent hw seems to have)... -Stefan > > Does it still make sense to build ubuntu-desktop-i386.iso? Validate > it? Test it on amd64 hardware? Ship it? > > To me this seems like a futile effort. Imho, we should only test the > relevant multiarch i386 pieces that are there to support 3rd-party, > i386-only apps on amd64 desktop. > > This is specifically about building, validating and shipping > ubuntu-desktop-i386.iso, specifically for the Ubuntu Desktop flavour. > Which I am suggesting should be dropped. Without any other changes to > the archive and/or publishing i386 binaries. > signature.asc Description: OpenPGP digital signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu Desktop on i386
On 2 February 2016 at 03:12, Bryan Quigley wrote: > The plan from the session we did over a year ago was: > "Specifically the Ubuntu (x86_32) desktop CD will be moved to cdimage > around opening of 16.10". The argument is that it was easy to build > the CD and it was cheap to do. It would be a community build that > wouldn't be promoted on the Ubuntu website or officially tested. > > It doesn't make sense to stop building the CD unless: > * We make the unity packages x86_64 bit only (what's the point in > having less easy to test latest 32-bit unity packages?) > * We drop x86_32 bit kernel support (guessing not something to > consider until after 18.04?) > Kernel support is a separate vector. E.g. in Debian it is common to install 32-bit userspace with the 64-bit kernel. Thus using all the CPU/kernel features, access all the memory, yet have lower memory utilisation. > I think it also makes sense to see if other derivatives want to go > x86_64-bit only like maybe Kubuntu (like I believe project Neon > targets just 64 bit). At some point we are going to want drop x86_32 > kernel support and just have 32-bit compatibility libraries, but I > don't know when that makes sense. > > Also, does Valve Steam product rely on i386 multiarch binaries? > Yes, it does, but it also downloads it's own Steam runtime with it's > own libraries. > > And Netflix - does that run on amd64-only without i386 > multiarch? I believe that runs completely with libs if you use Google Chrome. > Oh, and also Google Chrome is dropping Linux x86_32 bit support. > > I'm also happy to revisit my survey [2] and see where people are today. > I'm not sure it's about where people are, but rather where we want people to be. My argument for dropping .iso, but keeping the packages/archive is as follows: * we would like to support upgrades, for those that have 32 bit install * but we would like to prevent any new installations * because any new installation is amd64 capable, or such is the Ubuntu Desktop ISO installer requirement for 16.04 LTS * reduce releases.ubuntu.com mirror costs by about a third Otherwise, all survey results will remain constant. Building images is cheap, however I do not believe we can actually adequately support i386 ones for ubuntu desktop: * there is no i386-only certified hardware * image manual testing has a cost * no ubuntu developers use them =) Could we start the sunset period with removing flavour dropdown from the ubuntu desktop download pages for 16.04? (But keep the i386 images on releases.ubuntu.com?) http://www.ubuntu.com/download/desktop It has been switched to amd64 by default some time ago. Regards, Dimitri. > Thanks for bringing this up again! > Bryan > > [1] https://blueprints.launchpad.net/ubuntu/+spec/development-1411-drop-x86-32 > [2] https://bryanquigley.com/crazy-ideas/32-bit-usage-survey-results > [3] > http://summit.ubuntu.com/uos-1411/meeting/22353/when-should-we-stop-making-32-bit-images/ > > On Mon, Feb 1, 2016 at 5:14 PM, Dimitri John Ledkov wrote: >> Hello, >> >> Ubuntu has an i386 port which is fully supported. >> >> There a bunch of 3rd party applications that rely on the Multi-Arch >> technology to support/use i386 binaries on amd64 (e.g. Skype from the >> partner archive). BTW, can we ask Microsoft to publish native amd64 >> binaries, rather than those that rely on multi-arch i386? Also, does >> Valve Steam product rely on i386 multiarch binaries? or is it fully >> amd64? (and e.g. downloads/bundles/ships any required i386 binaries >> that it needs)? And Netflix - does that run on amd64-only without i386 >> multiarch? >> >> However, it seems to me that this is done specifically on otherwise >> full amd64 installations. >> >> My guess is that: all currently shipped hardware, with enough support >> to run full Unity (7) Desktop, is amd64. Tested with amd64 kernel, and >> amd64 graphics drivers. And hardware validation is done on amd64 too. >> >> In 2016, people with i386-only hardware are unlikely to be capable to >> run Unity 7 Desktop, and probably run other Ubuntu variants. I guess >> there are some accidental i386 users, e.g. those that have installed >> i386 variant on amd64 hardware. >> >> Does it still make sense to build ubuntu-desktop-i386.iso? Validate >> it? Test it on amd64 hardware? Ship it? >> >> To me this seems like a futile effort. Imho, we should only test the >> relevant multiarch i386 pieces that are there to support 3rd-party, >> i386-only apps on amd64 desktop. >> >> This is specifically about building, validating and shipping >> ubuntu-desktop-i386.iso, specifically for the Ubuntu Desktop flavour. >> Which I am suggesting should be dropped. Without any other changes to >> the archive and/or publishing i386 binaries. >> >> -- >> Regards, >> >> Dimitri. >> >> -- >> ubuntu-devel mailing list >> ubuntu-devel@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Regards, Dimitri. --
Re: Ubuntu Desktop on i386
The plan from the session we did over a year ago was: "Specifically the Ubuntu (x86_32) desktop CD will be moved to cdimage around opening of 16.10". The argument is that it was easy to build the CD and it was cheap to do. It would be a community build that wouldn't be promoted on the Ubuntu website or officially tested. It doesn't make sense to stop building the CD unless: * We make the unity packages x86_64 bit only (what's the point in having less easy to test latest 32-bit unity packages?) * We drop x86_32 bit kernel support (guessing not something to consider until after 18.04?) I think it also makes sense to see if other derivatives want to go x86_64-bit only like maybe Kubuntu (like I believe project Neon targets just 64 bit). At some point we are going to want drop x86_32 kernel support and just have 32-bit compatibility libraries, but I don't know when that makes sense. Also, does Valve Steam product rely on i386 multiarch binaries? Yes, it does, but it also downloads it's own Steam runtime with it's own libraries. And Netflix - does that run on amd64-only without i386 multiarch? I believe that runs completely with libs if you use Google Chrome. Oh, and also Google Chrome is dropping Linux x86_32 bit support. I'm also happy to revisit my survey [2] and see where people are today. Thanks for bringing this up again! Bryan [1] https://blueprints.launchpad.net/ubuntu/+spec/development-1411-drop-x86-32 [2] https://bryanquigley.com/crazy-ideas/32-bit-usage-survey-results [3] http://summit.ubuntu.com/uos-1411/meeting/22353/when-should-we-stop-making-32-bit-images/ On Mon, Feb 1, 2016 at 5:14 PM, Dimitri John Ledkov wrote: > Hello, > > Ubuntu has an i386 port which is fully supported. > > There a bunch of 3rd party applications that rely on the Multi-Arch > technology to support/use i386 binaries on amd64 (e.g. Skype from the > partner archive). BTW, can we ask Microsoft to publish native amd64 > binaries, rather than those that rely on multi-arch i386? Also, does > Valve Steam product rely on i386 multiarch binaries? or is it fully > amd64? (and e.g. downloads/bundles/ships any required i386 binaries > that it needs)? And Netflix - does that run on amd64-only without i386 > multiarch? > > However, it seems to me that this is done specifically on otherwise > full amd64 installations. > > My guess is that: all currently shipped hardware, with enough support > to run full Unity (7) Desktop, is amd64. Tested with amd64 kernel, and > amd64 graphics drivers. And hardware validation is done on amd64 too. > > In 2016, people with i386-only hardware are unlikely to be capable to > run Unity 7 Desktop, and probably run other Ubuntu variants. I guess > there are some accidental i386 users, e.g. those that have installed > i386 variant on amd64 hardware. > > Does it still make sense to build ubuntu-desktop-i386.iso? Validate > it? Test it on amd64 hardware? Ship it? > > To me this seems like a futile effort. Imho, we should only test the > relevant multiarch i386 pieces that are there to support 3rd-party, > i386-only apps on amd64 desktop. > > This is specifically about building, validating and shipping > ubuntu-desktop-i386.iso, specifically for the Ubuntu Desktop flavour. > Which I am suggesting should be dropped. Without any other changes to > the archive and/or publishing i386 binaries. > > -- > Regards, > > Dimitri. > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Ubuntu Desktop on i386
Hello, Ubuntu has an i386 port which is fully supported. There a bunch of 3rd party applications that rely on the Multi-Arch technology to support/use i386 binaries on amd64 (e.g. Skype from the partner archive). BTW, can we ask Microsoft to publish native amd64 binaries, rather than those that rely on multi-arch i386? Also, does Valve Steam product rely on i386 multiarch binaries? or is it fully amd64? (and e.g. downloads/bundles/ships any required i386 binaries that it needs)? And Netflix - does that run on amd64-only without i386 multiarch? However, it seems to me that this is done specifically on otherwise full amd64 installations. My guess is that: all currently shipped hardware, with enough support to run full Unity (7) Desktop, is amd64. Tested with amd64 kernel, and amd64 graphics drivers. And hardware validation is done on amd64 too. In 2016, people with i386-only hardware are unlikely to be capable to run Unity 7 Desktop, and probably run other Ubuntu variants. I guess there are some accidental i386 users, e.g. those that have installed i386 variant on amd64 hardware. Does it still make sense to build ubuntu-desktop-i386.iso? Validate it? Test it on amd64 hardware? Ship it? To me this seems like a futile effort. Imho, we should only test the relevant multiarch i386 pieces that are there to support 3rd-party, i386-only apps on amd64 desktop. This is specifically about building, validating and shipping ubuntu-desktop-i386.iso, specifically for the Ubuntu Desktop flavour. Which I am suggesting should be dropped. Without any other changes to the archive and/or publishing i386 binaries. -- Regards, Dimitri. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Patch pilot report: 2015-02-01
Hello everybody, here's what I got done in my shift today: Syncs: - syncpackage -b 1539921 -s ari-tczew cmd2 -f Uploads: - pad.lv/1540268 - fonts-ipaexfont-mincho package provides incorrect alias - pad.lv/1539845 - Enable raw image support - pad.lv/1539699 - please merge libgpod from debian - pad.lv/1532883 - [SRU] xcffib tries to dlopen an unavailable lib lp:~hackedbellini/ubuntu/wily/xcffib/fix-for-1532883 - ~sil2100/unity-settings-daemon/multi-arch - pad.lv/1518053 - xdg-mime can read .config/ defaults but can never set them Commented: - pad.lv/1535686 - please merge libgksu 2.0.13~pre1-8 from debian gksu-run-helper seems to have changed location during the merge, not sure if this has an impact on depending packages Closed: - pad.lv/1532799 - [Merge] gettext 0.19.7-2 from debian unstable already merged in xenial Have a great day, Daniel -- Get involved with Snappy Ubuntu Core! developer.ubuntu.com/snappy/ Follow @ubuntudev on twitter.com/facebook.com/G+ -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Fonts-droid has been deprecated and removed, please update your dependency :)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I'm sending this email to you because you are listed as contact for one or more packages affected by the fonts-droid package removal, to make you aware of the new fonts-android package (currently in - -proposed) where no fonts-droid is packaged anymore. Currently two choices are available: - - use fonts-droid-fallback (in universe) - - switch to fonts-noto, the replacement for fonts-droid (preferred solution). quoting upstream and the Debian bug reports: "Since Android upstream stopped shipping Droid fonts and its been declared that Noto fonts will be superseding the Droid¹² we in "Debian Fonts Task Force" team decided to drop fonts-droid package." ² http://lists.alioth.debian.org/pipermail/pkg-fonts-devel/attachments/201 51031/011f4334/attachment.mht ¹ https://github.com/googlei18n/noto-fonts/issues/555 Following there is an incomplete list of affected packages. (incomplete because Debian is fixing the affected packages "in sync" with Ubuntu) Please test and fix your packages if possible, I would like to avoid changing stuff without knowing exactly how to test the particular font. (and sorry for cross-posting, but I don't know a better way) thanks! Gianfranco Reverse-Recommends == * gnome-shell-pomodoro-data * hockeypuck [amd64 i386] * kubuntu-desktop [amd64 arm64 armhf i386 powerpc ppc64el] * kubuntu-full [amd64 arm64 armhf i386 powerpc ppc64el] * ubuntu-desktop [amd64 arm64 armhf i386 powerpc ppc64el] * ubuntu-gnome-desktop [amd64 arm64 armhf i386 powerpc ppc64el] * ubuntukylin-desktop [amd64 arm64 armhf i386 powerpc ppc64el] * ubuntustudio-desktop [amd64 arm64 armhf i386 powerpc ppc64el] * wesnoth-1.12-data * wine1.6 [amd64 i386] * xubuntu-desktop Reverse-Depends === * blender * cinnamon-desktop-environment * mythtv-common * request-tracker4 * ubuntu-keyboard-data * ubuntu-mate-core * ubuntukylin-theme * ubuntustudio-default-settings * ubuntustudio-font-meta [amd64 arm64 armhf i386 powerpc ppc64el] * xubuntu-default-settings -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJWr3F0AAoJEPNPCXROn13ZcHcQAM9CdlnQEi99gQt89cVhnDY4 9nuyCVs7n6Yxa6dK840PXg0ZIfVYpVfbn2kS6yqSgUJFnE8d5yFOiibL0qIJAihO ChVJNXmDf98iAiq7OlIrI4qg2GaXSrz8VbJO40VxJek64s5CzFzrtdvIAHm/CkCB oGbK4uFpFIykaOgfltaCPLWVyfXIwWKWSGGHUMnYmP4BC9D6Cb1fbcsbOgwN7gH7 wPHEKMRiqEEOEoFuXxixULg+7kkA4KnSTsDMYGdmOZfhC10SHtJmNGBnjzkEkHff hpkdWPjHvBBQANoQ/BRPNdR6Zc08527a1drQAAShojJyVy3/JSXsFc1kx7GFDbqx sOlVBq8lJXoEqlbQaJ+2AtfBmK0dunqVA+Ux1nGY9hNuPLzXJ39EraW/7Ll1iM7M uDBGezjx/HiDKPEqUUs3wA1snfnnwgDlCr7+u8WgJ4T6z3vcTC34uLMoOyvfpLm+ lSn2q5VpRqmcsCB+VAyOkwrigsUEDgVKrHcOBoCYmiAdCwHtlZG+xiHitVfwcA+E +LKjA5w/VghCb/WBH8X9ObNNrTD6XE8k8ICC8cR7Toms5FQHKRqjkIJc/A1nlkJY m2jE4iz6g2tiso2Uz0NrdjfTD15LqMzQ8Yjz6Rba/M9X1YmoKbElqQ87b4TZbNK7 /ZKCScGFzlPLxYlpmFPi =36gN -END PGP SIGNATURE- -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Error linking i386 build on Launchpad
2016-01-11 13:40 GMT+01:00 Colin Watson : > On Mon, Jan 11, 2016 at 11:46:24AM +0100, Cesare Falco wrote: > > I'm not able to build the current release of Mame on Launchpad due to > > memory issues: > > > > /usr/bin/ld: failed to set dynamic section sizes: Memory exhausted > > > > Did anyone find any workaround? Is there any way to tell Launchpad I > need a > > VM with more memory? Or perhaps I can force the build on a specific > machine > > which has more memory? > > There are various linker options which can help reduce memory taken > while linking, e.g. -Wl,--no-keep-memory, -Wl,--reduce-memory-overheads, > or -Wl,--hash-size=NUMBER. I can't quite tell what you're doing right > I've tried many combinations and ended up setting them all, with NUMBER being as little as 2, but with no luck. :( In the meantime, a new upstream version popped out; the latest build log is here: https://launchpad.net/~c.falco/+archive/ubuntu/alpha/+build/8920070/+files/buildlog_ubuntu-wily-i386.mame_0.170-0ubuntu1~ppa1~wily1_BUILDING.txt.gz > now because your build hides the exact command lines in use (please > reconsider that), but have you looked into those? > I enabled the verbose build which no longer hides the command lines. This produces a *big* file i.e. several megabytes: should I keep it anyway once the issue is solved? I thought it advisable to limit the building output, isn't it? Thank you! Cesare -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
