[01:18] <TheMuso> /c/c
[03:49] <RAOF> └─(13:48:%)── dpkg --compare-versions 1.4.0+git2012.is.really.1.4.0-0ubuntu1 gt 1.4.0+git20101207.0d32bb07-0ubuntu2 || echo false
[03:49] <RAOF> false
[03:50] <RAOF> What crazy subtlety of dpkg version comparing am I missing here?
[03:54] <ajmitch> RAOF: so, using 1.4.0+git20120101.is.really.1.4.0-0ubuntu1 seems to work, though the date is now a lie
[03:54] <micahg> right
[03:54] <RAOF> Yeah, it's odd.
[03:55] <micahg> no, it makes sense in the context of versioning
[03:55] <RAOF> 1.4.0+git2012 > 1.4.0+git2010, but 1.4.0+git2012 < 1.4.0+git201001
[03:55] <micahg> 20101207 > 2012
[03:55] <RAOF> Ooooh.
[03:56] <RAOF> dpkg treats *all* numbers in the version string as numbers rather than strings?
[03:56] <micahg> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version might be worth a read
[03:56] <micahg> it goes chunk by chunk and compares AFAICT
[03:57] <micahg> so, 1.4.0+git20101207.is.really.1.4.0-0ubuntu1 should also work
[05:07] <mux_> Hi everyone, for my project I have decided to build a user-friendly desktop automation software for Ubuntu (like AppleScript and Automator). I know that ubuntu already has a powerful scripting environment (bash etc) So is it worthwhile to follow my idea?? Also what other features should i include to make it not redundant?? Thank You.
[05:09] <lifeless> make it a) not suck and b) work with GUI programs.
[05:10] <RAOF> To expand upon b) - you need to do something like hooking into GTKActions, which would be accessible via the same mechanisms as the HUD uses.
[05:26] <mux_> RAOF: what is the demand for GUI desktop automation on linux...is it a problem worth solving?? or should we just tell users to learn BASH,python etc..?
[05:27] <mux_> lifeless: how often do you find the need for such softwares on Ubuntu...?
[05:36] <RAOF> mux_: The non-GUI scripting landscape is pretty solid.
[05:36] <RAOF> mux_: It's also my understanding that one of the major features of AppleScript & Automator is that they *do* cover GUI apps.
[08:28] <Sweetshark> Anyone here being able to help me debug that C++11 ABI mess? Starting LibreOffice on Quantal, New Presentation, Close -> Crash. Doesnt happen on precise.
[08:28] <Sweetshark> I tried to make a sense out of LD_DEBUG=all output, but did not find anything obviously dirty injecting std::list<> symbols there.
[08:28] <Sweetshark> mlankhorst: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1027043 <- here is the stacktrace
[08:28] <Sweetshark> Has anyone a good systematic proposal on how to proceed?
[08:46] <geser> Sweetshark: if nobody gives you a better idea, try to rebuild the LO (c++-based) dependencies with gcc-4.6 to check which ones "triggers" it (try boost first if you already didn't try it)
[08:51] <Sweetshark> geser: all >1000 (direct and indirect) deps? *cough* and what do I do with the rest of my work items this cycle?
[08:53] <geser> that many?
[08:59] <Sweetshark> geser: LibreOffice integrates with everything -- thus it can get the dirty C++11 ABI from virtually anywhere in main.
[09:05] <Sweetshark> geser: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1027043/comments/9 <- a feeble try at finding the source.
[09:05] <geser> Sweetshark: did you ask chrisccoulson how he found the problematic library in his unity case?
[09:07] <geser> Sweetshark: you could try to continue to "upgrade" it slowly (as far as dependencies allow it) towards quantal till you find the right package (or set of packages)
[09:39] <goddard> how can i find out what a library is called so i can link it using cmake?
[09:53] <mcclurmc> has the location for the R-series UDS been published yet?
[13:43] <bluefoxxx> apparently people have made grub4dos load by 'kexec -l grub2.exe'
[13:44] <bluefoxxx> has anyone managed to get grub itself to load via kexec?
[14:01] <stgraber> seb128, NCommander: ping (12.04.1 meeting in #ubuntu-meeting)
[14:31] <SpamapS> ugh, I think I stepped in bug 965371 ... this TLSv1.2 stuff is *sticky*
[15:08] <barry> slangasek: around?
[15:46] <hallyn> so uploading to -proposed is also for hot bugs right, not just for low-prio features?
[15:47] <micahg> hallyn: in a stable release?  it's not for features at all
[15:47] <hallyn> no in quantal
[15:47] <hallyn> during the current freeze
[15:48] <micahg> it's for anything on an image or anything that will cause installability issues
[15:48] <hallyn> ok
[15:49] <micahg> hallyn: this email explains it: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-July/000968.html
[15:49] <hallyn> hggdh: I'm going to push the fix for your qemu-kvm bug to q-proposed right now.
[15:49] <hallyn> micahg: yeah, what i wasn't sure about was, for things which are blocking qa, is it worth pushing to quantal and respinning
[15:49] <hallyn> i'm taking the asnwer as no
[15:49] <hallyn> no wait :)
[15:49] <micahg> hallyn: ask in #ubuntu-release :)
[15:50] <hallyn> ok thanks :)
[15:52] <mcclurmc> i'm the upstream maintainer for a package in debian and ubuntu. it depends on qemu, but the paths to qemu are different on Debian and Ubuntu. is there a standard way to maintain a patch on top of a Debian package, so that the Ubuntu package points to the right qemu location?
[16:02] <micahg> mcclurmc: http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/, see #4
[16:02] <mcclurmc> thanks, micahg
[16:28] <hggdh> hallyn: thanks
[16:35] <mcclurmc> micahg: thanks for the link raphael's blog. unfortunately, it wasn't what i needed
[16:36] <micahg> mcclurmc: not the specifics, but the general concept should be there (dpkg-vendor in debian/rules)
[16:36] <mcclurmc> i need to be able to apply one patch to the upstream source if the package is on debian, and a different patch if the package is on ubuntu
[16:36] <mcclurmc> is there a way in debian rules to selectively apply patches from debian/patches?
[16:36] <micahg> mcclurmc: ah, then you need a series.DEBIAN and series.UBUNTU file in debian/patches
[16:36] <mcclurmc> ah ha!
[16:36] <mcclurmc> yes, i do need that :)
[16:36] <tumbleweed> watch out for those, it's easy for them to become stale for the other distribution
[16:36] <micahg> a lot of packages feed dynamic paths through debian/rules which is why I suggested the blog post
[16:37] <tumbleweed> because you generally only work on one of them
[16:37] <micahg> mcclurmc: right, both need the full set of patches
[16:37] <mcclurmc> is there documentation for this? a quick google didn't find me anything
[16:38] <PaoloRotolo> Hi all!
[16:39] <micahg> mcclurmc: http://raphaelhertzog.com/2010/11/05/managing-distribution-specific-patches-with-a-common-source-package/
[16:39] <mcclurmc> micahg: i should probably read the rest of his blog too, shouldn't i?
[16:40] <micahg> heh, buxy tries hard to disseminate valuable information for distro collaboration
[17:32] <adam_g> ScottK: re bug #1021530, is it correct to prepare a new package for -proposed with the patch that will fix the tests/FTBFS?
[17:33] <ScottK> adam_g: Yes.  Also, if they have other fixes that meet the SRU criteria, they should be considered as well (as I mentioned in the bug).
[19:43] <carif> i recently heard a rumor that jockey was going away, is that true? will there be a replacement?
[19:49] <micahg> carif: https://lists.ubuntu.com/archives/ubuntu-devel/2012-July/035553.html
[19:50] <carif> micahg, dude, ty!
[20:43] <Laney> hallyn: upload away
[20:46] <skaet> thanks Laney
[20:46] <Laney> np
[20:47] <barry> kenvandine: ping
[20:48] <kenvandine> barry, pong
[21:26] <Laney> A3 is out. Get it while it's hot! :-)