[03:00] robert_ancell: do you know why gnome-control-center wasn't updated to 3.6? [03:01] robert_ancell: could be the dozens of patches we're holding I suppose [03:01] mfisch, it has to be done at the same time as gnome-settings-daemon [03:01] and that had some side-effects I believe [03:01] the plan is to do it this cycle though [03:03] robert_ancell: is there a test PPA that has them updated anywhere? [03:03] mfisch, https://launchpad.net/~ubuntu-desktop/+archive/ppa [03:04] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [03:04] robert_ancell: what are the odds of me being able to install 3.6 on my dev box and then going back to 3.4 without exploding my system? [03:04] mfisch, there's also a PPA for the gstreamer migration https://launchpad.net/~ubuntu-desktop/+archive/gstreamer1.0 [03:04] probably safe? [03:05] (haven't tried it myself) [03:05] robert_ancell: I'm trying to pick up an upstream fix that affects N7 [03:05] ah [03:05] well, reinstalls are entertaining anyway, so I'll do it [03:05] what's the fix? [03:06] robert_ancell: well actually I think it's not fixed, https://bugzilla.gnome.org/show_bug.cgi?id=662117 [03:06] Gnome bug 662117 in Screen "Brightness slider doesn't sync with the current value" [Normal,Resolved: fixed] [03:06] robert_ancell: I pulled that into the quantal version of g-c-c and it didn't solve the issue [03:07] robert_ancell: from what I can tell it was fixed in gnome in 3.4 and the 3.6 tree [03:07] yeah, looks that way [03:07] "fixed" in quotes [03:07] for some defintion of fixed [03:07] since the fix doesn't work for me, so I'll try the 3.6 and see since it should have the "fix' also [03:08] * robert_ancell fires up his n7 [03:08] robert_ancell: the n7 has 2 issues that I think this "fix" should fix, let me find them [03:09] robert_ancell: #1077096 and #1077054 [03:10] mfisch, btw is it a known problem on the n7 where the input locks up and you can select but not click on anything? [03:10] robert_ancell: yep, thats our biggest issue [03:11] mfisch, any ideas what it is? [03:11] but you read the Known Issues section of the wiki, I'm sure, so you already know all about it [03:11] robert_ancell: #1068994 button1 gets stuck after a while [03:11] robert_ancell: It's an X issue IIRC [03:11] why of course I did... :/ [03:11] Daniel D'Andrada is working on it [03:12] robert_ancell: the only solution is to reboot when that happens unfortunately [03:12] yeah, at least it reboots fast! [03:14] robert_ancell: and the unity greeter looks really good too, no scaling issues [03:14] yeah it's nice [03:15] mahjongg is the best app on the touchscreen [03:15] okay, rebooting with this new g-s-d [03:16] I guess a logout will do [03:22] yes [03:23] robert_ancell: gnome-settings-daemon died :( [03:24] not a good sign [03:24] my laptop is blindingly bright, better than too dim to read I guess [03:29] mfisch, is it in-scope to modify the theme so the window controls are clickable (i.e. win7 shaped) [03:29] robert_ancell: close/minimize etc? [03:29] mfisch, yes [03:30] I think we have a bug filed about that actually. [03:30] I couldn't see it [03:30] let me find it [03:31] robert_ancell: https://bugs.launchpad.net/ubuntu-nexus7/+bug/1075470 [03:31] ? [03:31] Launchpad bug 1075470 in ubuntu-nexus7 "Titlebar buttons are unusably small for tablets/touchscreens and don't scale with the fonts/titlebar" [Medium,Confirmed] [03:31] ah, ta [03:32] was searching for window controls etc [03:33] robert_ancell: #ubuntu-arm is the designated channel for N7 question, but bugs like these make sense to discuss here too [03:34] oh, I thought I was in #ubuntu-desktop, didn't notice this was #ubuntu-devel [03:34] meh, too many channels anyway :) [03:35] robert_ancell: regarding that brightness bug, how does one go about testing the "pure gnome" version? [03:35] or how do you prove that it's not just the fault of the Ubuntu version? [03:36] mfisch, compile it locally. You'd have to replace the existing binary or do some hackery though [03:36] mfisch, with apps it's easy, but lower level stuff much harder. You can compile the package with the patches disabled [03:37] option B might be easier [03:37] as long as none of the patches are strictly required (which is generally the case) [03:41] * robert_ancell just realized he has 5 active screens in front of him [04:50] good morning [05:30] TheMuso: ping [05:30] regarding bug #1070631, what else is necessary? [05:30] Launchpad bug 1070631 in Banshee "[Sync libgpod 0.8.2-7 from Debian unstable to Raring] libgpod-cil contains arch-specific code but is declared arch:all" [Medium,Confirmed] https://launchpad.net/bugs/1070631 [05:31] TheMuso: the debdiff contains only a debian/changelog entry, and rightly so, because no other changes are needed to backport it. [05:31] TheMuso: it's sitting there as a debdiff because i can't upload libgpod myself. [05:33] hyperair: So its a no-change rebuild in quantal essentially... [05:33] TheMuso: -proposed. [05:33] Yeah well of course. [05:33] TheMuso: it's a *backport* of -7 which is in raring, into quantal-proposed. [05:34] not a rebuild of -6 which is in quantal. [05:34] urm... Shouldn't you then be pulling the patch from the -7 packaging? [05:34] yes it's to be applied against -7? [05:35] don't you see the context lines? [05:35] it says libgpod (0.8.2-7) unstable; urgency=low [05:35] [05:35] * [1c86366] Make -cil packages non-arch-all (Closes: #689054) [05:35] Yes I see that, but are you saying you want the entirity of -76 put into quantal-proposed? [05:35] yes. [05:35] *the entire -7 upload [05:35] yes. [05:36] do you need a debdiff against -6 for that? [05:36] Yes but I see 3 changes there that are not relevant to the SRU. [05:36] hang on, lemme check that.. [05:37] TheMuso: which 3 changes? [05:38] oh, okay, should i remove those? [05:38] Bump debhelper to 9, the standards version change, and the package section change. [05:38] All of which are in -7. [05:38] TheMuso: they're insignificant changes that don't result in any user-visible changes [05:38] -6 is already built against dh >=9 [05:39] in quantal, thatis [05:39] bumping that makes no difference [05:39] No, but I have seen the release team raise flags over changes like that that are not relevant to the SRU. [05:39] Yes, but if you change compat it can change how debhelper processes stuff. [05:39] ScottK: i didn't change compat. [05:39] ScottK: it's only bumping the build-dep version. [05:39] Oh. [05:39] ScottK: it was already on compat 9, build-depping on >= 8.9~ [05:39] 8.9~ -> 9 = no difference [05:40] SRU should be minimal. [05:40] I agree it's not needed. So it shouldn't be there. [05:40] * hyperair sighs [05:40] fine, i'll strip it === fenris is now known as Guest99083 === Guest99083 is now known as ejat [06:11] TheMuso: alright, i've uploaded the new patch. [06:31] hyperair: Ok, I'm taking care of it now. [06:32] thanks [07:20] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: diwic [07:25] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [07:59] good morning [07:59] hey dholbach [07:59] hi pitti [08:00] dholbach: tu n'est pas dans #ubuntu-quality ? [08:00] dholbach: ah, maintenant! [08:00] pitti, oui, je suis là [08:02] bonjour / good morning / Guten Morgen === smb` is now known as smb [08:03] geser: доброе утро! [08:03] :) [08:09] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: diwic [08:11] * dholbach hugs diwic [08:11] * diwic hugs dholbach === tkamppeter_ is now known as tkamppeter === fenris is now known as Guest72215 === Tonio_aw is now known as Tonio_ === mcclurmc_away is now known as mcclurmc === mcclurmc is now known as mcclurmc_away === _salem is now known as salem_ === Tonio_ is now known as Tonio_aw === Tonio_aw is now known as Tonio_ === mcclurmc_away is now known as mcclurmc [11:53] Seems that I have hit a ghost dependency in apt-get making it impossible to use apt-get again. I have installed "ia32-libs' trying to install some closed-source app and ia32-libs is uninstallable as some i386 library versions did not get built. Now "apt-get install -f" insists on installing the uninstallable libraries, even after removing all :i386 packages [11:54] to be complete tkamppeter would like to "undo" the "those new packages will be installed" and doesn't know how [11:55] installing them fail due to what looks like cairo/avahi multiarch bugs: [11:55] http://pastebin.ubuntu.com/1357786/ [11:55] " trying to overwrite shared '/usr/share/doc/libcairo-gobject2/README.gz', which is different from other instances of package libcairo-gobject2:i386" [11:55] bug #1078625 [11:55] Launchpad bug 1078625 in cairo (Ubuntu) "package libcairo-gobject2 1.12.2-1ubuntu2.1 failed to install/upgrade: trying to overwrite shared '/usr/share/doc/libcairo-gobject2/README.gz', which is different from other instances of package libcairo-gobject2:i386" [Undecided,New] https://launchpad.net/bugs/1078625 [11:56] pitti, I hope that gzip bug is not back [11:56] urgh [11:56] * seb128 does like those README.gz being different between arches [11:56] doesn't* [11:56] well, the avahi error in on README (not .gz) so not like that... [11:58] seb128, pitti, I cannot even help myself by uninstalling all :i386 packages (ias32-libs I haver already uninstalled). Then "apt-get -f install" wants to install all :i386 packages again. There seems to be some hard ghost dependency on at least some of the i386 libraries making the broken libraries required. [11:59] tkamppeter, did you try to dpkg -r them? [11:59] hum [11:59] /usr/share/doc/libcairo-gobject2/README.gz -> ../libcairo2/README.gz [11:59] the file which is different is a symlink [12:01] the README.gz in libcairo2 amd64 and i386 have the same md5 it seems (from dpkg-deb the debs) [12:01] wonder if that's a but in dpkg/apt [12:02] that is a tkamppeter upload [12:02] oh, so maybe local build [12:02] I bet he installed his self built deb which has different files [12:02] md5sums* [12:02] Laney, good thinking! [12:03] same for avahi [12:03] tkamppeter, does wget https://launchpad.net/ubuntu/+source/cairo/1.12.2-1ubuntu2.1/+build/3923069/+files/libcairo2_1.12.2-1ubuntu2.1_amd64.deb && dpkg -i it fixes the cairo error? [12:03] Laney, thanks for pointing that ;-) [12:03] it's a "fun" corner case situation [12:03] @pilot out [12:03] @pilot out === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: === ogra-cb_ is now known as ogra-cb [12:05] seb128, pitti, no change: http://pastebin.ubuntu.com/1357813/ [12:05] tkamppeter, wget https://launchpad.net/ubuntu/+source/cairo/1.12.2-1ubuntu2.1/+build/3923069/+files/libcairo-gobject2_1.12.2-1ubuntu2.1_amd64.deb and dpkg -i it and try again? [12:08] seb128, now the libcairo error went away and only libavahi stuff is remaining. [12:08] same fix [12:09] tkamppeter, wget https://launchpad.net/ubuntu/+source/avahi/0.6.31-1ubuntu2/+build/3889306/+files/libavahi-common3_0.6.31-1ubuntu2_amd64.deb [12:09] tkamppeter, wget https://launchpad.net/ubuntu/+source/avahi/0.6.31-1ubuntu2/+build/3889306/+files/libavahi-client3_0.6.31-1ubuntu2_amd64.deb [12:09] tkamppeter, dpkg -i those [12:13] seb128, yes, now it works. Thanks. [12:13] tkamppeter, yw! === cpg is now known as cpg|away === cpg|away is now known as cpg === Tonio_ is now known as Tonio_aw === Tonio_aw is now known as Tonio_ === cpg is now known as cpg|away [12:58] Hi, I'm trying to mark a bug fixed for quantal but not yet fixed for precise. I can't seem to find the correct way to do this in launchpad, can anybody please give me a hint? [13:00] marga, you will have to nominate the bug for precise [13:00] alright, how do I do that? [13:00] I'm talking about the launchpad interface. [13:00] marga, then someone with the correct access (possibly yourself, if you're a developer) can accept the nomination [13:01] I've seen this in plenty of bugs, a subitem inside the package (Ubuntu) with a small clock [13:01] "Nominate for series" link [13:01] Do you have a "Nominate for series" option just below the bug metadata? [13:01] You have to be in a certain team (ubuntu-bugcontrol IIRC) to even see that [13:01] I don't. [13:01] Then you need to ask somebody who is [13:01] cjwatson, oh, I didn't know that [13:02] Ok. Good, I think I was going crazy or something. [13:02] s/think/thought. [13:02] https://wiki.ubuntu.com/UbuntuBugControl [13:03] marga, is there a specific bug you want me to nominate for you? [13:03] https://bugs.launchpad.net/ubuntu/+source/dropbear/+bug/834174 [13:03] Launchpad bug 834174 in dropbear (Debian) "cannot login via ssh when using dropbear in initramfs" [Unknown,New] [13:03] It's been uploaded to raring-proposed, but I'd like this to be also fixed in precise. [13:04] marga, done, you should now see a nomination [13:05] diwic, thanks [13:18] marga: diwic: and nomination accepted. [13:18] tnx [13:19] * xnox will play around with this on the weekend, unless somebody beats me to testing it. [13:19] I've changed the desc and the debdiff. Hopefully I've folllowed SRU guidelines now. [13:21] marga: the real test case is that you can ssh in & unlock the drive. [13:22] marga: the bug is that above is not possible due to bugs in discovering / generating initramfs on a system with multiarch [13:25] ok, feel free to update my desc :) === MacSlow is now known as MacSlow|lunch === fisted_ is now known as fisted === MacSlow|lunch is now known as MacSlow [13:33] cjwatson: The Ubuntu Studio team wants to know when will the blender python fix go into raring-main (not -proposed) === attente_zzz is now known as attente [13:37] sbhw: it's being transitioned by britney: check the output here http://people.canonical.com/~ubuntu-archive/proposed-migration/ [13:37] as to why it's possibly stuck. [13:38] sbhw: so the armhf build has just finished, and not fully published yet for britney to attempt transition to main. [13:44] sbhw: Yeah, this is all automatic [13:44] sbhw: They should be a bit more patient since I only uploaded it an hour or two ago [13:45] And given that none of them fixed it in the multiple days that it was broken ... ;-) [13:46] cjwatson, can't undetstand the system. They want to know it since that they almost just want to remove it from the seeds. [13:46] That's a daft response :) [13:46] It'll be fixed in an hour or two [13:47] sbhw: "the bug will be marked fix released at the time it's migrated into the raring-release pocket." [13:47] yep [13:54] cjwatson: sorry for the noise, i had commented blender out of our meta to make sure the iso would build and was just curious on an ETA so i had a general approximation of when i needed to uncomment blender [13:54] again, sorry for the trouble [13:59] scott-work: well, generally it's ~1h after fully built on all arches, that is if it's actually installable and doesn't cause other packages to become uninstallable.... but blender takes a while to build on arm [14:02] xnox: i'd like to use this as a teachable moment for myself; is -proposed an "in box" or queue for building then pushing into the repos? [14:03] i realized in uds-q there was discussion about changing how the repos are structured, i am certainly not up to date on this and the processes [14:03] scott-work: it's the same thing as in debian: unstable -> testing transition. [14:03] scott-work: but we _do not_ impose the "10 day delay", nor rc-bugs. [14:04] ah, okay. thank you :) [14:04] scott-work: we plan to block on failing auto-pkg-test of the package or any of it's reverse-depends. [14:04] scott-work: but that is not done yet. [14:07] thank you again, xnox [14:07] scott-work: np. blender is in release now, in ~0.5h it should be pushed to the mirrors. [14:07] the storm is over. [14:12] cjwatson: jibel and I would like to meet with you soon to discuss adt/britney integration; when would be a good time for you? [14:14] pitti: any time tomorrow would be lovely, if that suits [14:14] cjwatson: yes, it does; how does 10:00 UTC sound? [14:15] scott-work: https://lists.ubuntu.com/archives/ubuntu-devel/2012-October/036043.html [14:15] pitti: sure [14:15] thanks [14:15] just grab me and we can hop on mumble or something [14:19] oooh, thank you cjwatson , i will definitely read that [14:45] sforshee, wrt my USB dongle, can I run trace-cmd for a long time? it sometimes takes all day before it disconnects [14:46] rickspencer3, the only risk is the size of the trace.dat file getting very large. You could check it periodically and restart trace command if the file is getting too big. All I'm really interested in is the part of the trace right before the disconnect happens. [14:47] ok sforshee [14:47] thanks [14:47] it's running now [14:47] rickspencer3, also please grab dmesg after killing trace-cmd so I can try to correlate the two [14:47] sforshee, ack [14:47] (that is after the disconnect happens) [15:09] why is the util-linux package still source format 1.0 with no patch system? [15:11] psusi: ask its maintainer; 3.0 isn't a requirement and some people still like it the old way for one reason or another === Quintasan_ is now known as Quintasan [15:12] Or of course sometimes it's just hadn't-got-round-to-it [15:14] doko_: bug 1017125 should be good for quantal SRU. I also prepared a mpi package. both boost1.49_1.49.0-3.1ubuntu1.1.dsc and boost-mpi-source1.49_1.49.0-3.1ubuntu1.1.dsc waiting on chinstrap. [15:14] Launchpad bug 1017125 in boost1.49 (Ubuntu Quantal) "[SRU quantal] boost::unordered_multimap<>::erase(iterator, iterator) broken in boost1.49" [High,New] https://launchpad.net/bugs/1017125 [15:14] I mean I thought we were not supposed to just directly make changes to the upstream source without some sort of patch system? [15:15] psusi: in general yes, but also we are not suppose to diverge from debian way of maintaining the package. [15:15] psusi: sometimes the two conditions conflict with each other, if debian has no patch system. [15:16] yea, but isn't it better to add a patch system than to have the upstream sources mangled? [15:17] and would it be worth while for me to try to update the package to 3.0 (quilt) and submit it to the debian maintainer? [15:18] or just dive in and make changes directly to the upstream source? [15:23] psusi: dive in ;-) [15:23] psusi: that's what we do for all native packages as well.... [15:23] psusi: or use the bzr lp:ubuntu/$pkg branches. [15:24] if individual changes are committed you get a normal vcs history. [15:26] psusi: if you don't wand to have a mix of directly applied patches and patches from patch system, you would have to ideally transfer those directly applied patches to patch files too (and make the delta even bigger) [15:27] often those changes are bigger than the patch you wanted to apply and you have to merge it everytime [15:27] but feel free to convince the Debian maintainer to use a patch system [15:28] psusi: We should never change the patch system in an Ubuntu delta [15:28] That includes adding one [15:28] psusi: But as geser says, feel free to try to persuade the Debian maintainer that they want to change [15:29] It's not fair to describe the upstream sources as being mangled - that's why we have .orig.tar.gz / .diff.gz [15:30] psusi: and you might have a better chance to get you patch included in Debian if you don't change the whole packaging system [15:31] Exactly [15:33] yea, but doesn't having them all squashed into the diff.gz make for conflict galore when you update to a new upstream? [15:33] Sweetshark, done [15:34] psusi: Not particularly, no [15:34] and since they aren't seaparted out, resolving them is next to impossible? [15:34] Sure, you may have to know the package depending on the complexity of the changes [15:34] Anyway, this isn't the point [15:34] Merging a new Debian version is much more common for us than merging a new upstream directly [15:34] We should therefore optimise for not creating huge numbers of conflicts against Debian [15:35] (Also, I believe the util-linux maintainer uses git to maintain the packaging against upstream and does not find this to be a particular problem for his workflow; hence why you should talk to him ...) [15:36] hrm... well, I guess I'll just make the change directly then... just thouguht that make merging a pita [15:40] Like I say, it's a matter of optimising for merging against Debian vs. upstream [15:40] doko_: awesome, thanks [15:41] I mean, we *could* in theory aggressively convert every non-native package in Ubuntu to 3.0 (quilt), but then we'd end up assuming significantly more merge workload [15:41] It doesn't make economic sense [15:42] And it doesn't make social sense either since a number of the Debian maintainers we'd like to work with would consider that very rude [15:43] doko_: Sweetshark: thanks a lot ;-) [15:47] hi, I want to update upstream version for a package (geos - from 3.3.3 to 3.3.5) [15:48] I did 'bzr branch ubuntu:geos', then 'dch -i', updated version to 3.3.5, then bzr bd -S [15:48] but it complains that "unexpected upstream changes detected" and tries to create a patch [15:49] when I create it I can't build the package anymore... [15:49] dpkg-source: error: cannot read geos-3.3.5.orig.ND5giv/debian/patches/update-to-3.3.5: No such file or directory [15:49] ppawel: did you merge the new upstream tarball? [15:50] ppawel: cause following your instructions the diff will have the reverse between 3.3.5 -> 3.3.3 [15:50] ppawel: $ bzr merge-upstream ../geos-3.3.5.tar.gz [15:50] ppawel: instead of `dch -i` [15:50] yeah it doesn't apply to 3.3.3... [15:50] xnox, thanks, I will try that [15:51] ppawel: but your branch is dirty now, so move it aside and try again. [15:56] xnox, thanks it works now [16:28] doko_, how do you feel about promoting libboost-filesystem-dev and libboost-system-dev (and associated 1.49 versioned packages)? [16:28] (libunity test suite needs them) [16:29] er, rather nux test suite needs them [16:30] mterry, sure, why not? but I don't see these in component-mismatches yet [16:31] doko_, no, not yet. was planning ahead. though, I'm not sure a branch adding these as build-depends will get through the PS landing process unless they are in main. didrocks? [16:33] doko_: hmm.... componen-mismatches doesn't work that well with everything going via -proposed. [16:34] doko_: e.g. bug 1077484 doesn't show libsemanage in component-mismatches [16:34] Launchpad bug 1077484 in shadow (Ubuntu) "[MIR] libsemanage (shadow's rdep to continue SELinux support in shadow)" [Undecided,Confirmed] https://launchpad.net/bugs/1077484 [16:35] hmm [16:35] xnox: that's on the to-do lit [16:35] *list [16:36] I'm asking Ursula to have a look at that [16:37] cjwatson: ok. thanks. [16:46] barry: what's next with https://code.launchpad.net/~mvo/ubuntu-release-upgrader/lp1071388/+merge/132851 in your opinion? === mcclurmc is now known as mcclurmc_away [17:01] mterry: so, theorically it can [17:01] mterry: but as we'll have soon daily upload, it's better to just merge it when we have the build-dep in main [17:01] doko_: ^ [17:03] didrocks, what am I supposed to merge? [17:04] doko_: we are talking about the merge request for the packaging adding the build-dep === deryck is now known as deryck[lunch] [17:21] kenvandine: hey, did I hear you right in CPH that you were working on a new Gwibber thing? [17:21] yeah [17:21] the service has been rewritten [17:21] the client still needs to be ported to the new backend [17:21] kenvandine: ah, but the frontend is the same.. thing? [17:21] but the backend is rocking! [17:21] yeah [17:21] for now :) [17:21] well [17:22] negronjl: ^^ [17:22] there is the unity lens too [17:22] for 13.04 we'll be removing the client [17:22] and just shipping the lens [17:22] ah [17:22] removing, or just demoting? [17:22] and hopefully expanding the lens functionality a bit [17:22] just not seeding it [17:22] right, cool [17:23] nice [17:32] bdmurray: nothing, i think. [17:33] I uploaded a source package to my PPA. will the derivative packages be built for me? === doko_ is now known as doko [17:38] barry: so you think its okay to merge and upload? [17:41] bdmurray: check w/mvo. he said he fixed the couple of things i mentioned, but the diff in the mp doesn't look updated. not sure he pushed his changes. === mcclurmc_away is now known as mcclurmc [18:06] doko, sorry, getting back from lunch. I think didrocks's point was that it might be easier with the PS process if the archive were ready as we test the branches. Which means pre-promoting. [18:07] right ;) [18:10] doko, so I guess the ask is to pre-promote libboost-filesystem-dev and libboost-system-dev (and associated 1.49 versioned packages), assuming they don't need a full MIR === deryck[lunch] is now known as deryck [18:28] slangasek: so using udevadm trigger --subsystem-match=misc --action=change for /dev/kvm, the main downside i'm seeing (beside expectec container weirdness) is that if kvm module is not loaded, but /dev/kvm was manually created, perms on it won't get fixed. i don't know if we care about that case. [18:32] mahmoh: any chance you could verify bug 589063 ? [18:32] Launchpad bug 589063 in seabios (Ubuntu Lucid) "Windows Server 2008 won't boot with more than 4 vCPUs" [Undecided,Fix committed] https://launchpad.net/bugs/589063 [18:37] * apw just installed a Q system from scratch and when trying to upgrade it to R i found it was in "LTS only" mode ... is that right? === Ursinha-afk is now known as Ursinha === attente is now known as attente_zzz [18:55] hallyn: why would something manually create /dev/kvm? Also, if the kvm module is not loaded, isn't /dev/kvm non-functional? [18:58] slangasek: correct, it wouldn't be functional. This would be some obtuse test case. [18:58] hallyn: right; so when the kvm module was loaded, udev would trigger and update the permissions on /dev/kvm anyway [18:58] hallyn: static /dev is not a configuration we support [18:59] it's not? that's too bad :) [18:59] slangasek: ok, i'l go ahead and push this change. thanks! === mcclurmc is now known as mcclurmc_away [19:40] james_w: does pkgme support python3? [19:40] (as in packaging python3 software) [19:44] xnox: so llvmpipe on panda is sufficiently horrid that running compiz at all, even just for ubiquity, is almost certain to be unusable. === rickspencer3_ is now known as rickspencer3 [19:54] slangasek: Has anyone tested that theory this cycle? ogra was telling me that llvmpipe on his Chromebook is actually pretty usable and the Chromebook, while certainly faster than a Panda, isn't exactly a computing powerhouse. [19:57] infinity: I haven't tested, but I don't see how a massive port of LLVMpipe to NEON would have magicked itself up overnight [19:57] feel free to test and prove me wrong :) [19:58] My Panda's somewhat preoccupied with building glibc for 5 distributions. [19:58] When it stops crying, maybe I'll ask it to do GUI things to a monitor. [19:59] sad panda is sad [20:00] It's a masochist, it's okay. === attente_zzz is now known as attente === yofel_ is now known as yofel === Tonio_ is now known as Tonio_aw === cpg|away is now known as cpg === cpg is now known as cpg|away [21:12] is armhf busted? https://launchpad.net/ubuntu/+source/firefox/17.0~b6+build1-0ubuntu1/+build/3983790 === mcclurmc_away is now known as mcclurmc [21:25] slangasek: *sigh* well I have a workitem to implement it and I was hoping panda will be better than VM or old-laptop. I guess i'll use one of those in development, and then smoke test on the panda. [21:27] mterry: did you know about `pull-lp-source $package {$distro,$distro-$pocker,$version}` & `pbuilder-dist $distro {create,update,clean,build,login}` which has support for _all_ ubuntu & debian releases? [21:27] mterry: well the first-one changes to pull-debian-source. [21:27] xnox, you're talking about instead of pbuilder-scripts? [21:28] mterry: yeah. Or what is unique in pbuilder-scripts which is missing in ubuntu-dev-tools. [21:28] SpamapS: where do we stand with copying up SRUs? [21:28] if possible I'd like to avoid uploading webkit twice ... [21:29] xnox, I wrote those scripts when working with OEMs and needing all sorts of custom sources. So supporting standard ubuntu and debian releases wasn't a big feature [21:29] mterry: There is a request to backport it to precise, but I just don't see what it offers extra / on top of what ubuntu-dev-tools already offer for a very long time including stable releases. [21:29] mterry: so if ubuntu-dev-tools add [easy] support for extra sources it will be match? [21:29] mterry: so if ubuntu-dev-tools adds [easy] support for extra sources it will be match? [21:29] mterry: anything else? [21:30] * xnox wants to consolidate tools, scripts, utilities around ubuntu-dev-tools if possible. [21:31] xnox: even if someone did magic up an LLVMpipe port to NEON, it would still be slower than in kvm [21:31] \o/ http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00455.html \o/ [21:31] gcc.gnu.org bug 2012 in c "ICE when compiling the current cvs gcc as cross-compiler to mingw32" [Critical,Resolved: duplicate] [21:31] xnox, I'm for consolidating. I'd have to go through and figure out the various features though. Easy sources is one. apt-get update before building. apt-get sourcing using the sources in one of the chroot [21:31] slangasek: ok. [21:32] chrisccoulson: armhf busted> there was mention about the livefs builder having "tar errors" as well, but I don't have details [21:33] infinity, ogra-cb: ^^ any ideas? https://launchpadlibrarian.net/123040342/buildlog_ubuntu-raring-armhf.firefox_17.0~b6%2Bbuild1-0ubuntu1_FAILEDTOBUILD.txt.gz [21:33] mterry: i'll open a bug about those three. If there is anything else, feel free to do wishlist bugs against ubuntu-dev-tools. [21:33] slangasek, thanks [21:34] that's the same kind of error we saw on celbalrai, yeah [21:36] xnox, it also lays out the sources in a certain way & uses that layout to automatically determine which project chroot you want it to operate on (can be overridden). Not sure if ubuntu-dev-tools can easily support that stle [21:36] style [21:36] Laney: ok, it was the same bunzip2 problem? [21:36] mterry: hmm... well pbuilder-dist already auto-supports guesing/using multiple combinations of distro's and arches. [21:36] slangasek: I think so [21:37] infinity: do you have a raring panda handy? [21:37] mterry: the whole point of pbuilder-dist was to allow easily manage chroots for all releases & cross-arches, since it's common for ubuntu developers to build against multiple ubuntu releases (sru/security/backports) and debian releases (for bug verification /forwarding to debian) [21:38] slangasek: I could do, but like I said earlier, my Panda's a bit busy. [21:38] mterry: so I am sure it can be extended to handle sub-types of chroots. [21:38] infinity: ah, still? thbt [21:38] ok [21:38] infinity: well, bzip2 hasn't changed in raring, so I guess I'll open a critical bug against eglibc in the meantime [21:39] slangasek: Also, if this build log ever loads.. If it's bunzip2 spontaenously having a fit, that's been happening on ARM for years. [21:39] oh, it has? [21:39] Yeah. Though, it usually manifests before the build starts (when untarring the chroot). [21:39] I've never heard of it until Laney mentioned it happening on celebrityrye this week [21:40] And it's so wildly unreproducible, no one's managed to hunt it down. [21:40] celbalrai's issues seem unrelated. [21:40] not according to Laney [21:40] now it has died, but before that we were seeing similar errors [21:40] Laney: do you have a pointer to such an error? [21:40] Similar, or the same? [21:40] p'raps I have a log which is nonempty [21:41] mterry: adding all of these requests to the wishlist =)))) keep them coming. [21:41] infinity: similar, because the livefs builder doesn't generally go about unpacking firefox tarballs :P [21:41] yeah that's wishful thinking [21:42] slangasek: Well, yes. And I would have assumed the errors were just "something from some sort of compression something or other" which is hardly "the same error". [21:42] xnox, :) [21:42] mterry: we are soon gonna get shiny cross-building support ;-) [21:43] mterry: and that will want easy custom repositories as well =) [21:43] nice [21:43] mterry: with and without qemu execution. [21:43]