[01:18] <bernie> hey, i think i've hit a bug in software-center with installing commercial software after it has been paid for.
[01:18] <bernie> where could i report it?
[01:19] <micahg> bernie: ubuntu-bug software-center
[01:37] <bernie> micahg: i ended up filing this https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1008289
[01:37] <ubottu> Launchpad bug 1008289 in software-center (Ubuntu) ""Failed to download repository information" for purchased application" [Undecided,New]
[01:38] <bernie> micahg: and i also sent a note to pay-support@canonical.com
[01:38] <micahg> bernie: ok, someone should be looking at it tomorrow then
[01:39] <bernie> micahg: it's just $9.99, but i'm very curious to see what the customer experience is like.
[01:39] <micahg> bernie: indeed, I think it's something that should work :) (I just don't work on that), sounds like you already took the proper steps
[03:11] <bernie> micahg: hey, i found another workflow that triggers bugs in the software center: 1) purchase the humble indie bundle 2) you get an email with a key and a link 3) click on "Download for Ubuntu" to get to software-center.ubuntu.com with the key in the url 4) click on one of the apt:// links and Software Center opens 5) Software Center offers you to buy the game once again :-(
[03:11] <bernie> micahg: i'll report another bug
[03:14] <micahg> bernie: ok, thanks
[03:35] <bernie> micahg: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1008309
[03:35] <ubottu> Launchpad bug 1008309 in software-center (Ubuntu) "Can't download purchased Humble Indie Bundle with Ubuntu Software Center" [Undecided,New]
[03:36] <pitti> Good morning
[03:39] <ajmitch> morning pitti
=== jbicha is now known as Guest40326
[04:24] <ion> Hmm, Psychonauts doesn’t seem to be available yet.
[04:35] <vibhav> Can https://bugs.launchpad.net/ubuntu/+source/libdvdnav/+bug/934471 be nominated for oneiric and precise?
[04:35] <ubottu> Launchpad bug 934471 in libdvdnav (Ubuntu) "vlc crashed with SIGSEGV in dvdnav_describe_title_chapters()" [Medium,Fix released]
=== tkamppeter_ is now known as tkamppeter
[07:02] <dholbach> good morning
=== smb` is now known as smb
[08:16] <larsduesing> good morning
=== dholbach_ is now known as dholbach
=== Guest33157 is now known as Adri2000
[10:26] <tjaalton> dholbach: hey, could you test the kernel from precise-proposed to see if it fixes bug 906269 for you?
[10:26] <ubottu> Launchpad bug 906269 in xserver-xorg-video-intel (Ubuntu) "[sandybridge-m-gt2+] GPU lockup render.IPEHR: 0x7a000002" [High,Incomplete] https://launchpad.net/bugs/906269
[10:27] <tjaalton> it did work for dovercash
[10:27] <dholbach> tjaalton, the lockup only happened very rarely, so it'll be a bit hard to test it, but AFAIK I didn't have any video lockups for a longer while now
[10:27] <dholbach> sorry for the very unspecific feedback
[10:28] <tjaalton> dholbach: ok, I'll mark it as a dupe of the other one then. there are a couple of other commits I'll propose to be added to v3.2-stable if the testing goes well..
[10:28] <dholbach> ok cool
[10:28] <dholbach> thanks a bunch
[10:28] <tjaalton> np, thanks
=== MacSlow is now known as MacSlow|lunch
=== Guest40326 is now known as jbicha
[12:18] <ahasenack> good morning! Can a sponsor please take a look at #1004678? Thanks
[12:20] <tumbleweed> ahasenack: that bug has no ubuntu tasks. It's also worth mentioning that you need a core-dev when asking for sponsorship :)
[12:21] <ahasenack> tumbleweed: right, let me add one, and change ours to fix committed
[12:22] <ahasenack> tumbleweed: do I need to subscribe some other team too?
[12:23] <tumbleweed> no, it should appear on the sponsorship queue
[12:26] <ahasenack> tumbleweed: ok
=== ara_ is now known as ara
=== _salem is now known as salem_
=== MacSlow|lunch is now known as MacSlow
=== barry` is now known as barry_
=== barry_ is now known as barry
=== zyga is now known as zyga-afk
=== yofel_ is now known as yofel
=== salem_ is now known as _salem
=== _salem is now known as salem_
[13:50] <kendfinger> Hello
[14:05] <kendfinger> Any events today?
[14:08] <dobey> what sort of events?
[14:09] <dobey> an ELE is unlikely today, at least
[14:09] <seb128> could somebody reject https://code.launchpad.net/~penguin359/ubuntu/precise/network-manager/fix-for-1005091-precise/+merge/107545
[14:09] <seb128> (it's a request against the wrong branch, the contributor also submitter other ones)
[14:10] <stgraber> seb128: done
[14:11] <seb128> thank
[14:11] <seb128> thanks
[14:12] <dobey> can someone accept the ubuntuone-client and ubuntuone-control-panel packages into precise-proposed?
[14:16] <kendfinger> Like meetings.
[14:18] <kendfinger> Is there a buildbot or something for the Quantal Cd images?
[14:19] <seb128> stgraber, could you reject https://code.launchpad.net/~kroq-gar78/ubuntu/precise/activemq/sid-merge/+merge/106539 as well?
[14:19] <kendfinger> Is it true apport is being replaced?
[14:19] <stgraber> seb128: done
[14:20] <seb128> thanks
=== salem_ is now known as _salem
=== _salem is now known as salem_
[14:27] <stokachu> Daviey: ping
[14:27] <stokachu> or xnox ping :)
[14:28] <xnox> ?
[14:28] <xnox> =)
[14:28] <xnox> stokachu: what's up?
[14:28] <stokachu> xnox: hey, im trying to patch autofs5 in lucid, but dpatch-edit-patch new old fails with no rule to make unpatch
[14:28] <stokachu> xnox: is there something special i need to be doing for the patch system in autofs
[14:29] <xnox> stokachu: not in the new autofs. Let me grab lucid's autofs and see how that acient package was done =)
[14:29] <stokachu> xnox: ok thanks, i believe its pretty ancient
[14:34] <xnox> stokachu: are you trying to add a patch, or edit / modify an existing one?
[14:34] <xnox> I would do
[14:34] <stokachu> yea a new patch
[14:34] <xnox> ./debian/rules clean
[14:34] <xnox> add a patch file to ./debian/patches/
[14:35] <xnox> add the name of the patch to ./debian/patches/00list
[14:35] <xnox> make sure the patch starts with #! /bin/sh /usr/share/dpatch/dpatch-run
[14:35] <xnox> and then do a test build
[14:35] <stokachu> ah ok -- a more manual approach
[14:35]  * micahg suggest edit-patch
[14:36] <xnox> micahg: if you know how to operate it, go ahead =)
[14:36]  * xnox only used dpatch the way I described about 3 times in my lifetime =)
[14:36] <stokachu> micahg: i tried dpatch-edit-patch but that failed with no makefile rule to unpatch
[14:36] <stokachu> is edit-patch better to work with?
[14:37] <xnox> stokachu: the packaging is very old-school, so it does not have upatch targets.
[14:37] <micahg> edit-patch is an abstraction on dpatch-edit-patch, not sure of all the pitfalls
[14:37] <stokachu> ah ok
[14:37]  * micahg defers to xnox
[14:37] <stokachu> they both break in the same way
[14:38] <stokachu> manual way it is then
[14:38] <stokachu> thanks xnox
[14:39] <xnox> stokachu: I usually do $ bzr commit & bzr dep3-patch -c-1 > debian/patches/newpatch.patch
[14:39] <dholbach> bryceh, tjaalton: did we have any xvfb segfaults any time recently? it might be a problem with bug 1008537 - not confirmed yet
[14:39] <ubottu> Launchpad bug 1008537 in sphinx (Ubuntu) "[FTBFS] Segmentation fault during tests" [Undecided,New] https://launchpad.net/bugs/1008537
[14:40] <stokachu> xnox: ok cool ill test that
[14:40] <pitti> bryceh, tjaalton: FWIW, I get crashes in xvfb in apport's test suite, too
[14:40] <xnox> stokachu: and then edit the series/00list & top line for the dpatch stuff.
[14:40] <stokachu> ok
[14:44] <tjaalton> dholbach, pitti: there have been no xserver updates to quantal other than one bugfix early May..
[14:44] <tjaalton> so it could be something else triggering it
[14:45] <dholbach> tjaalton, for a test, I could upload the sphinx merge to a precise ppa and see what happens
[14:45] <tjaalton> dholbach: yeah
[14:45] <dholbach> do we have some docs on how the buildd chroots are configured?
[14:45] <dholbach> it'd be good to be able to reproduce this somewhere outside LP
[14:46] <xnox> dholbach: the buildd tarball is accesible to download & then you can run it with sbuild
[14:46] <xnox> should be very close to LP setup
[14:46] <xnox> chroot tarball
[14:46] <dholbach> xnox, I think I'd better leave that to somebody who knows how to debug xvfb better :)
[14:47] <dholbach> but it's good to know
[14:47] <xnox> =))))
[14:47] <xnox> true
[14:54] <tjaalton> dholbach: from the buildlog you can see that it actually managed to pass the first iteration of the tests, but the second one failed
[14:54] <dholbach> https://launchpad.net/~dholbach/+archive/ppa/+build/3547669 will start in 6h
[14:55] <tjaalton> the precise build log shows it'll run the tests three times
[14:56] <tjaalton> ah, the old version was built on oneiric
[14:56] <tjaalton> hum no
[14:56] <tjaalton> that was the kernel version :)
[14:56] <tjaalton> the one on precise-proposed built fine
[15:12] <bdmurray> mvo: bug 902603 is still receiving duplicates because people are release upgrading without the new version of dpkg.  can something be done about that?
[15:12] <ubottu> Launchpad bug 902603 in taglib (Ubuntu Precise) "When installing Multi-Arch: same (meta-)package for two architectures, dpkg considers one arch as completely disappeared" [High,Fix released] https://launchpad.net/bugs/902603
[15:16] <kendfinger> Today's quantal build is very unstable! I can't connect to wifi. it freezes alot, and it just is flat out slow.
[15:22] <ogra_> kendfinger, we didnt even release alpha1 yet, what would you expect :)
[15:22] <kendfinger> I know. Just wanted to help by submiting bugs. :)
[15:23] <ogra_> yeah, thats a good plan :)
[15:30] <mvo> bdmurray: one not very user friendly way would be to put it into DistUpgrade.cfg as "BadVersions=dpkg_1.16.0.3ubuntu5"
[15:30] <mvo> bdmurray: this would mean people without it get a error, better of course is to simply install the update first
[15:31] <bdmurray> mvo: and is there a way to accomplish that?
[15:31] <seb128> could somebody reject https://code.launchpad.net/~nathwill/ubuntu/precise/gnome-control-center/fix-lp-978118/+merge/103784
[15:31] <seb128> (wrong serie, need tweaking, should go to Debian)
[15:32] <stgraber> seb128: done
[15:32] <seb128> stgraber, thanks
[15:33] <mvo> bdmurray: I think this needs a bit of code to be written, let me double check
[15:47] <mvo> bdmurray: not, not trivially, we would have to write some code
[15:49] <bdmurray> mvo: okay, its only received 7 duplicates in the past 2 weeks so may not be worth it
[16:04] <seb128> could somebody set https://code.launchpad.net/~sacridex/ubuntu/precise/unity-greeter/purple-background-on-startup-fix/+merge/102679 to needs fixing or rejected?
[16:05] <stgraber> seb128: done
[16:05] <seb128> thanks
=== nhandler_ is now known as nhandler
=== JonEdney is now known as 15SABW5FP
[16:25] <jtaylor> what should be done with fftw3? it now depends on mpi in debian, I guess thats not suitable for main?
=== ahasenack is now known as Guest47924
[16:42] <slangasek> seb128: hi, where did the number 800MB come from on https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-one-iso-for-q ?  My understanding was that it was supposed to be 750 MB for this cycle
[16:42] <slangasek> then at UDS I suggested we bump it to 750MiB instead because we were already at 736MB
[16:43] <slangasek> now we're bumping again :)
[16:43] <Riddell> it seems pretty arbitrary
[16:43] <Riddell> Kubuntu is hopeing for 1GB which is arbitrary but nicer and round :)
[16:43] <seb128> slangasek, hey, I'm a bit out of the loop on the topic, not sure if there was an UDS discussion if there was I missed it, please fix whatever I had wrong in the blueprint, jasoncwarner_ suggested I open it so we have an "official" place to track the change
[16:44] <seb128> slangasek, I got the 800mb number from https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001303.html
[16:45] <slangasek> Riddell, seb128: two cycles ago we had a discussion about dropping the CDs in favor of USB-sized images which would grow slowly each cycle, and it's my understanding the agreement was 750
[16:45] <slangasek> for this cycle
[16:45] <slangasek> pitti: hi, where'd the number 800MB come from in https://lists.ubuntu.com/archives/ubuntu-release/2012-June/001303.html ?  I know we had a hallway discussion in Oakland about doing 750MiB instead of 750MB, but I didn't remember anyone saying 800 :)
[16:45] <seb128> slangasek, well, as said I missed the discussion if there was one at UDS so you might be right
[16:47] <seb128> slangasek, btw since you are around, do you see any issue multiarching libbonoboui without doing libbonobo? from reading bug #977947 the libbonobo one is non trivial
[16:47] <ubottu> Launchpad bug 977947 in libbonobo (Ubuntu Quantal) "Please transition libbonobo to multi-arch" [Medium,Triaged] https://launchpad.net/bugs/977947
[16:47] <slangasek> seb128: they can be multiarched in any order, but we do need to get the whole stack to get any real benefit to users
[16:48] <seb128> slangasek, I'm trying to look at bug #1003964 for precise SRU
[16:48] <ubottu> Launchpad bug 1003964 in libgnomecanvas (Ubuntu Precise) "libglade2-0 can't find libbonobo.so or libcanvas.so (those need to be multiarched)" [Low,Confirmed] https://launchpad.net/bugs/1003964
[16:48] <seb128> slangasek, libglade got multiarched and load its .so from /usr/lib/i386-linux-gnu/libglade and those libs install a .so in /usr/lib/libglade
[16:48] <slangasek> seb128: I don't think I've looked at libbonoboui in depth... I certainly wouldn't *SRU* libbonoboui before libbonobo is sorted
[16:48] <seb128> slangasek, the other option would be to add a fallback loader to libglade
[16:49] <seb128> that might be a safer solution for precise
[16:49] <roaksoax> 4
[16:49] <slangasek> erm... yes, there should be loader fallbacks for such things
[16:49] <seb128> slangasek, ok, I will look into that, thanks ;-)
[16:49] <slangasek> thank you :)
[16:49] <slangasek> stokachu: ^^ were you still looking at finishing up some of these multiarch SRUs for precise?
[16:51]  * micahg thinks he took a precise multiarch SRU and forgot to upload it
[16:53] <infinity> micahg: It's the thought that counts, right?
[16:55] <micahg> heh, I just need to go dig it up and upload later in the week
[17:11] <infinity> jdstrand: Care to have a quick look at bug 993658?
[17:11] <ubottu> Launchpad bug 993658 in latex2html (Ubuntu) "[MIR] latex2html" [Undecided,New] https://launchpad.net/bugs/993658
[17:12] <jdstrand> infinity: ok. it'll be a bit, but I'll get to it this afternoon
[17:12] <infinity> jdstrand: Sure.  Seems mostly like a no-brainer to me, at least.
[17:43] <seb128> slangasek, could you have a look to bug #987502? the patch submitter asked for your input
[17:43] <ubottu> Launchpad bug 987502 in libxml2 (Ubuntu) "libxml2-dev: /usr/bin/xml2-config isn't identical across all arch" [Medium,Triaged] https://launchpad.net/bugs/987502
[17:43] <slangasek> seb128: it's in my queue, yes
[17:43] <seb128> slangasek, thanks
[17:44] <slangasek> seb128: btw, should libbonoboui2-0 have a versioned dep on the version of libglade2-0 that looks in the multiarch directory?  (currently it doesn't)
[17:45] <seb128> slangasek, it should maybe breaks libglade << multiarch version rather?
[17:45] <slangasek> seb128: well, it already depends on libglade
[17:45] <slangasek> so it should depend on the right version of libglade :)
[17:46] <dobey> is there an sbuild equivalent of pbuilder-dist?
[17:46] <seb128> ok, I will fix that with the next upload, thanks for pointing it
[17:46] <slangasek> seb128: thank you!
[17:49] <jbicha> dobey: I don't think so, I just follow http://wiki.debian.org/sbuild to set it up
[17:59] <dobey> jbicha: ok, i'll check it out. thanks
[18:05] <dobey> do packages in quantal show up on errors.ubuntu.com now?
[19:04] <geser> dobey: take a look at "mk-sbuild - creates chroots via schroot and sbuild" (ubuntu-dev-tools), perhaps the script does what you are looking for
[19:10] <agrimm> hi, all.  I'm trying to figuring out how dpkg orders things during package upgrades.  I have a package A that depends on an exact version of package B, and I would expect that on upgrade, package B's "preinst" script for the new version would run before the new version of package A is unpacked... but this isn't what seems to happen.  is the ordering not that strict?  am I forced to use pre-depends if I need this behavior?
[19:11] <tumbleweed> correct, that's what Pre-Depends is for
[19:12] <tumbleweed> we try and avoid Pre-Depends whenever possible
[19:12] <tumbleweed> err sorry misread
[19:13] <tumbleweed> if A depends on B, A will be configured before B's postinst. If Pre-Depends, A will be configured before B's preinst runs
[19:13] <tumbleweed> http://www.debian.org/doc/debian-policy/ch-relationships.html
[19:40] <slangasek> agrimm: if you want unpack ordering, you have to use pre-depends, yes
[19:41] <agrimm> slangasek, tumbleweed : thanks, I'll see how that goes
[19:42] <slangasek> in general we discourage people from doing this however ;)
[19:42] <slangasek> as it makes the dependency calculations more brittle overall
[19:43] <cr3> for a python3 project in quantal, should the debian/control file specify something like: Depends: ${python3:Depends}? does that even exist?
[19:43] <agrimm> slangasek, I did see that in the guidelines... I really just need preinst script to run before unpacks ... it's strange to me that they don't
[19:43] <slangasek> the preinst script runs before the unpack of the package shipping it
[19:43] <agrimm> slangasek, understood
[19:43] <agrimm> but if that package _depends_ on another
[19:43] <slangasek> but there's no guarantee of unpack ordering *except* via pre-depends, because it is actually useful for the package manager to unpack things out of order in some cases
[19:44] <slangasek> usually when trying to resolve conflicts/breaks elsewhere in the dependency graph
[19:44] <slangasek> cr3: yes
[19:44] <slangasek> cr3: https://wiki.ubuntu.com/Python/3 should have the deets
[19:44] <agrimm> slangasek, I understand.  I'm just spoiled by package managers which have solved this problem
[19:44] <slangasek> cr3: actually, not that page, but on the linked http://wiki.debian.org/Python/LibraryStyleGuide
[19:45] <infinity> agrimm: As a result of the unpack ordering oddities, it's often recommended that preinsts not use anything outside of Essential.
[19:45] <slangasek> dpkg/apt have solved this too, just not with the same semantics as others ;)
[19:45] <infinity> agrimm: (Which is generally good advice anyway, preinsts shouldn't be where one does complex things)
[19:45] <slangasek> pre-depends are the correct way to enforce what you want
[19:45] <slangasek> we just recognize (probably better than others) that there's a cost to using pre-depends
[19:45] <cr3> slangasek: thanks, exactly what I needed!
[19:45] <agrimm> infinity, if this were for the install case, I'd agree with oyu, but my use case is strictly for upgrades, where I already know what's on the system
[19:46] <slangasek> one might note that Debian/Ubuntu actually support full release upgrades, whereas distros using certain other package managers do not
[19:46] <agrimm> slangasek, FWIW, I'm talking about conary as the "other package manager", not RPM
[19:46] <agrimm> :)
[19:46] <slangasek> ah ;)
=== Guest47924 is now known as ahasenack
=== salem_ is now known as _salem