Re: Multiarch in Oneiric for developers
Hi David, On Fri, Aug 26, 2011 at 12:00:38AM +0200, David Henningsson wrote: On 2011-08-16 20:46, Steve Langasek wrote: As part of the work to eliminate ia32-libs in favor of multiarch library installation (https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-multiarch-next-steps), i386 sources have been enabled by default on amd64 systems in oneiric. For new installs, this is done by default in alpha-3 and above; and as of today, update-manager also ensures that i386 multiarch support is enabled by default on upgrade from natty. I'm sure this is all great and something many people have been waited eagerly for, but for my own part I must say I have missed the newbie introduction wiki/blog, or Multiarch for dummies. [1] Yes, the information so far has not been targeted at end users because there hasn't been anything for users to directly *use* until now. I'm intending to put something in the beta release notes about this. I also gave a talk at DebConf about multiarch (slides[1], video[2]), which briefly covers the why bother? aspect among other things; and there's http://wiki.debian.org/Multiarch/TheCaseForMultiarch which tries to lay out the problem space multiarch is designed to address. As to your specific questions, answers are inline below: 1) If I'm an Ubuntu end user who likes to watch youtube videos, what does multiarch mean to me and what advantages will I notice? The end user is not likely to directly notice any advantages with respect to youtube videos - or at least, not ones that are obviously attributable to multiarch. What multiarch does is let us make the ia32-libs compat package obsolete, rendering an entire class of bugs irrelevant: because the 32-bit libraries are now delivered to the amd64 user the same way as they are to the i386 user, we will no longer have bugs (including security bugs) remaining unfixed in an unwieldly all-or-nothing compatibility package, nor will we have bugs *caused* by stale copies of libraries in ia32-libs. (Ask any of the X guys how much fun it is to try tracking down the out-of-date copy of mesa in ia32-libs that mysteriously causes amd64 desktops to hang.) Beyond the removal of ia32-libs, which is still in progress, multiarch will also allow us to make many *more* 32-bit libraries available on the 64-bit desktop, instead of a hand-picked few libraries used by certain common applications. As a result, 32-bit software will in the long run be more usable on 64-bit systems, because we have a solution that scales (instead of ia32-libs which doesn't); and because of this improved compatibility, more users will be able to take fuller advantage of their 64-bit systems by running the amd64 architecture without fear that their 32-bit programs won't work. And the libraries that are converted for multiarch will work better than they did in ia32-libs. Longstanding (recurring) bugs related to search paths for gtk themes and other plugins are resolved by switching to multiarch. 2) As I understand Multiarch is a way to run i386 binaries on an amd64 system. [2] What are the typical i386 binaries you want to run on amd64? The typical ones for which we have multiarch library support in oneiric are skype and flash. There are three other 32bit-only closed-source packages in the Canonical partner archive that are not yet installable via multiarch: acroread, adobeair, and adobereader-deu. Wine, Google Earth, and ICA Client are other common 32-bit-only packages. There's plenty of other closed-source software for Linux that's also affected. 3) If I'm a packager of a random library, does multiarch affect my packaging? Is there anything I should be aware of or should it just work? (What if I use debhelper 7, or cdbs, etc?) http://wiki.debian.org/Multiarch/Implementation Hope that helps, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] http://people.debian.org/~vorlon/multiarch-six-years-on.pdf signature.asc Description: 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: [fedora-arm] ARM summit at Plumbers 2011
David: On Wed, Aug 24, 2011 at 6:55 PM, da...@lang.hm wrote: ARM is currently in worse shape than the PC market ever was in this aspect, but in this case it's less a matter of getting the hardware guys to change what they do than it is to get better documentation of what the hardware is really doing and not duplicating drivers for cases where the right answer is just replacing a constant with a variable (just as an example of the very common case where the same component is wired to a different address) I agree. Maybe Linaro or an equivalent organization could provide a ARM kernel janitor service to the community, where they refactor existing ARM platform/driver code to make it more common. This is something that's difficult for a single person with experience in only one or two SoCs to do, but it would be pretty straightforward work for a team of three or four people with broad coverage of the SoC devices the kernel supports now. As such refactoring consolidated larger and larger chunks of kernel code, new designs would gravitate towards those consolidated implementations because they would be the dominant references. b.g. -- Bill Gatliff b...@billgatliff.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [fedora-arm] ARM summit at Plumbers 2011
On Fri, Aug 26, 2011 at 11:11:41AM -0500, Bill Gatliff wrote: As such refactoring consolidated larger and larger chunks of kernel code, new designs would gravitate towards those consolidated implementations because they would be the dominant references. Don't bet on it. That's not how it works (unfortunately.) Just look at the many serial port inventions dreamt up by SoC designers - everyone is different from each other. Now consider: why didn't they use a well established standard 16550A or later design? Also consider why ARM Ltd designed the PL010 and PL011 primecells which are different from the 16550A. This need to be different is so heavily embedded in the mindset of the hardware people that I doubt providing consolidated implementations will make the blind bit of difference. I doubt that hardware people coming up with these abominations even care one bit about what's in the kernel. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [fedora-arm] ARM summit at Plumbers 2011
Russell: On Fri, Aug 26, 2011 at 11:35 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Aug 26, 2011 at 11:11:41AM -0500, Bill Gatliff wrote: As such refactoring consolidated larger and larger chunks of kernel code, new designs would gravitate towards those consolidated implementations because they would be the dominant references. Don't bet on it. That's not how it works (unfortunately.) I wasn't being clear. The Linux community isn't large enough to dictate to ARM SoC designers how their hardware should work--- mostly because the Linux community doesn't buy chips, corporations do. And it has been my experience that the parts of corporations that negotiate deals for the hardware aren't populated with the developers of the drivers for said hardware. What I meant was that as new hardware becomes available, if we have strong driver models then driver authors will adopt those APIs rather than inventing their own. I'm thinking about GPIO before gpiolib, for example. Or the current state of PWM. This need to be different is so heavily embedded in the mindset of the hardware people that I doubt providing consolidated implementations will make the blind bit of difference. I doubt that hardware people coming up with these abominations even care one bit about what's in the kernel. I don't routinely see a need to be different as existing strictly for its' own sake, even with the hardware guys. Rather, I see a lot of developers (hardware and software) that are so consumed with their own requirements and deadlines that they don't get the chance to step back and see the bigger picture. The resulting fragmentation is a symptom, not the disease itself. And honestly, some of the fragmentation is a really good thing. I love how Atmel does their GPIO controllers on the SAM-series parts, for example. The SODR and CODR registers are a godsend for concurrent code. We wouldn't have such treats if everybody did things the same way. So I'm generally ambivalent to the hardware situation. But that doesn't mean that the software has to be equally fragmented. In fact, I think the hardware situation necessitates that we pay particular attention to NOT fragmenting the drivers for said hardware. Gpiolib proves that is possible, something I didn't think I would find myself saying when David Brownell started his effort. I'm glad he proved me wrong. b.g. -- Bill Gatliff b...@billgatliff.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [fedora-arm] ARM summit at Plumbers 2011
russell, good to hear from you. can i recommend, that although this is a really wide set of cross-posting on a discussion that underpins pretty much everything (except gnu/hurd and minix) because it's linux kernel, that, just as steve kindly advised, we keep this to e.g. cross-dis...@lists.linaro.org? i'll be doing that from now on [after this] perhaps including arm-netbooks as well, but will be taking off all the distros. so - folks, let's be clear: please move this discussion to cross-dis...@lists.linaro.org, and, if it's worthwhile discussing in person, please do contact steve, so he can keep the slot open at the Plumbers 2011 summit. On Fri, Aug 26, 2011 at 5:35 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Aug 26, 2011 at 11:11:41AM -0500, Bill Gatliff wrote: As such refactoring consolidated larger and larger chunks of kernel code, new designs would gravitate towards those consolidated implementations because they would be the dominant references. Don't bet on it. That's not how it works (unfortunately.) Just look at the many serial port inventions dreamt up by SoC designers - everyone is different from each other. Now consider: why didn't they use a well established standard 16550A or later design? *sigh* because they wanted to save power. or pins. or... just be bloody-minded. This need to be different is so heavily embedded in the mindset of the hardware people that I doubt providing consolidated implementations will make the blind bit of difference. i think... russell... after they are told, repeatedly, no, you can't have that pile of junk in the mainline linux kernel, Get With The Programme, you'd think that, cumulatively if they end up having to maintain a 6mb patch full of such shit, they _might_ get with the programme? and if they don't, well who honestly cares? if they don't, it's not *your* problem, is it? _they_ pay their employees to continue to main a pile of junk, instead of spongeing off of _your_ time (and linus's, and everyone else's in the Free Software Community). I doubt that hardware people coming up with these abominations even care one bit about what's in the kernel. then don't f**g make it _your_ problem, or anyone else's, upstream!! :) this is the core of the proposal that i have been advocating: if it's selfish, i.e. as bill and many many others clearly agree with if the bang-per-buck ratio is on the low side then keep it *out* the mainline linux kernel... ... and that really is the end of the matter. the sensible people that i've been talking to about this are truly puzzled as to why the principles of cooperation and collaboration behind free software are just being... completely ignored, in something as vital as The Linux Kernel, and they feel that it's really blindingly obvious that the bang-per-buck ratio of patches to mainline linux kernel need to go up. so the core of the proposal that is the proposed selfish-vs-cooperation patch policy is quite simple: if the patch has _some_ evidence of collaboration, cooperation, refactoring, sharing - *anything* that increases the bang-per-buck ratio with respect to the core fundamental principles of Free Software - it goes to the next phase [which is technical evaluation etc. etc.]. otherwise, it's absolutely out, regardless of its technical correctness, and that's the end of it. the linux kernel mainline source tree should *not* be a dumping-ground for a bunch of selfish self-centred pathological profit-mongering corporations whose employees end up apologising in sheer embarrassment as they submit time-pressured absolutely shit non-cooperative and impossible-to-maintain code. you're not the only one, russell, who is pissed off at having to tidy up SoC vendors' patches. there's another ARM-Linux guy, forget his name, specialises in samsung: two years ago he said that he was getting fed up with receiving yet another pile of rushed junk... and that's *just* him, specialising in samsung ARM SoCs! we're just stunned that you, the recipient of _multiple_ SoC vendors piles of shite, have tolerated this for so long! anyway - i've endeavoured to put together some examples, in case that's not clear: i admit it's quite hard to create clear examples, and would greatly appreciate help doing so. i've had some very much appreciated help from one of the openwrt developers (thanks!) clarifying by creating another example that's similar to one which wasn't clear. http://lkcl.net/linux/linux-selfish.vs.cooperation.html this should be _fun_, guys. it shouldn't be a chore. if you're not enjoying it, and not being paid, tell the people who are clearly taking the piss to f*** off! but - i also would like to underscore this with another idea: lead by example (which is why i've kept the large cross-distro list) we - the free software community - are seeing tons of nice lovely android tablets, tons of nice lovely expensive bits of big iron and/or x86 laptops, and
data.tar.xz support added to Launchpad
It should now be possible to use xz compression for .deb packages uploaded to Ubuntu oneiric (using 'dh_builddeb -- -Zxz'). In order to do so, you must include this field in the relevant binary packages: Pre-Depends: dpkg (= 1.15.6) (This implies that such packages can only be uploaded to maverick and later.) Please do not use this for packages that are Priority: required or Priority: important, as you will break the installer if you do (and relaxing that restriction would have implications for people's ability to debootstrap Ubuntu on various minimal systems). Please check that it's actually worth compressing a package using xz before doing so! You can easily take the data.tar.gz, recompress it using xz, and compare the size. If you maintain a package that already uses -Zlzma, consider converting it to -Zxz; compression ratios should be similar, and it's a better-designed format. -- Colin Watson [cjwat...@ubuntu.com] -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [lsb-discuss] [fedora-arm] ARM summit at Plumbers 2011
I would relly like the dscussion to go on widely as it is now. Otherwise I would probably not follow this interesting discussion. best regards keld On Fri, Aug 26, 2011 at 10:02:09PM +0100, Luke Kenneth Casson Leighton wrote: russell, good to hear from you. can i recommend, that although this is a really wide set of cross-posting on a discussion that underpins pretty much everything (except gnu/hurd and minix) because it's linux kernel, that, just as steve kindly advised, we keep this to e.g. cross-dis...@lists.linaro.org? i'll be doing that from now on [after this] perhaps including arm-netbooks as well, but will be taking off all the distros. so - folks, let's be clear: please move this discussion to cross-dis...@lists.linaro.org, and, if it's worthwhile discussing in person, please do contact steve, so he can keep the slot open at the Plumbers 2011 summit. On Fri, Aug 26, 2011 at 5:35 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Aug 26, 2011 at 11:11:41AM -0500, Bill Gatliff wrote: As such refactoring consolidated larger and larger chunks of kernel code, new designs would gravitate towards those consolidated implementations because they would be the dominant references. Don't bet on it. ??That's not how it works (unfortunately.) Just look at the many serial port inventions dreamt up by SoC designers - everyone is different from each other. ??Now consider: why didn't they use a well established standard 16550A or later design? *sigh* because they wanted to save power. or pins. or... just be bloody-minded. This need to be different is so heavily embedded in the mindset of the hardware people that I doubt providing consolidated implementations will make the blind bit of difference. i think... russell... after they are told, repeatedly, no, you can't have that pile of junk in the mainline linux kernel, Get With The Programme, you'd think that, cumulatively if they end up having to maintain a 6mb patch full of such shit, they _might_ get with the programme? and if they don't, well who honestly cares? if they don't, it's not *your* problem, is it? _they_ pay their employees to continue to main a pile of junk, instead of spongeing off of _your_ time (and linus's, and everyone else's in the Free Software Community). ??I doubt that hardware people coming up with these abominations even care one bit about what's in the kernel. then don't f**g make it _your_ problem, or anyone else's, upstream!! :) this is the core of the proposal that i have been advocating: if it's selfish, i.e. as bill and many many others clearly agree with if the bang-per-buck ratio is on the low side then keep it *out* the mainline linux kernel... ... and that really is the end of the matter. the sensible people that i've been talking to about this are truly puzzled as to why the principles of cooperation and collaboration behind free software are just being... completely ignored, in something as vital as The Linux Kernel, and they feel that it's really blindingly obvious that the bang-per-buck ratio of patches to mainline linux kernel need to go up. so the core of the proposal that is the proposed selfish-vs-cooperation patch policy is quite simple: if the patch has _some_ evidence of collaboration, cooperation, refactoring, sharing - *anything* that increases the bang-per-buck ratio with respect to the core fundamental principles of Free Software - it goes to the next phase [which is technical evaluation etc. etc.]. otherwise, it's absolutely out, regardless of its technical correctness, and that's the end of it. the linux kernel mainline source tree should *not* be a dumping-ground for a bunch of selfish self-centred pathological profit-mongering corporations whose employees end up apologising in sheer embarrassment as they submit time-pressured absolutely shit non-cooperative and impossible-to-maintain code. you're not the only one, russell, who is pissed off at having to tidy up SoC vendors' patches. there's another ARM-Linux guy, forget his name, specialises in samsung: two years ago he said that he was getting fed up with receiving yet another pile of rushed junk... and that's *just* him, specialising in samsung ARM SoCs! we're just stunned that you, the recipient of _multiple_ SoC vendors piles of shite, have tolerated this for so long! anyway - i've endeavoured to put together some examples, in case that's not clear: i admit it's quite hard to create clear examples, and would greatly appreciate help doing so. i've had some very much appreciated help from one of the openwrt developers (thanks!) clarifying by creating another example that's similar to one which wasn't clear. http://lkcl.net/linux/linux-selfish.vs.cooperation.html this should be _fun_, guys. it shouldn't be a chore. if you're not enjoying it, and not being paid, tell the people
Re: python-gnomeapplet is not on Oneiric repositories
Jeremy Bicha a écrit le 2011-08-25 22:31 : Yes, Ubuntu Oneiric ships GNOME 3; Natty shipped GNOME 2.32. GNOME Panel 3 is available for install in the repositories but panel applets must be ported to gnome-panel 3 or else they simply won't run at all. python-gnomeapplet is no longer being developed as Python developers need to use GObject Introspection instead of PyGTK to work with GTK3. https://launchpad.net/ubuntu/+source/gnome-python-desktop/2.32.0-0ubuntu4 Thanks a lot for your answers. I'll point out them to the developer of cardapio. Regards, Jean-Philippe -- 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
