[00:15] psusi: Just ask your question, and I'll respond when I'm around. Whats up? [00:19] TheMuso, are you going to take over maintainership of dmraid in debian, or do you just have upload rights? [00:19] TheMuso, I have been trying to get our dmraid pages merged upstream and today I realized that debian has not updated to upstreams's last 3 releases... probably because they decided to call it .rc16-1, -2, and -3 [00:20] TheMuso, so today I rebased the patches on -3, which game out last year... and half of the patches went away as they were already merged.. I'd like to get debian and ubuntu both synced and up to date [00:21] TheMuso, the one patch I wasn't sure about was the disable-dmreg one, as it appears to disable important upstream functionality dealing with failed disks in a mirror, so I just left that patch disabled for now [01:24] slangasek: missing firmware for a network card on the alternate is a linux-firmware bug or something else? === doko__ is now known as doko [01:34] infinity, https://launchpadlibrarian.net/87009585/buildlog_ubuntu-precise-armhf.hscolour_1.19-2_FAILEDTOBUILD.txt.gz please build it in the bootstrap archive === lifeless_ is now known as lifeless [02:24] h [02:24] hi === user is now known as MonkFish [02:25] hail === cnd is now known as cndougla === cndougla is now known as cnd [02:47] infinity: will germinate ignore packages that are missing in the archive for a certain arch? I'm missing 8 packages for xubuntu-meta [02:49] micahg: It will [02:49] :(, I guess I'll wait till the weekend [02:52] micahg: I don't understand why you'll wait? It gives you a metapackage with whatever is there. Once you get the rest, then you just upload it again. [02:53] ScottK: xfwm4 is missing :) [02:53] I guess that's important ... [02:54] and a few other xubuntu core packages [02:56] hopefully by Sat night, I should be able to upload (no rush anyways) [03:05] micahg: got around to updating bug #900421 if you're bored and in a sponsoring mood [03:05] Launchpad bug 900421 in libsigc++-2.0 (Ubuntu) "Please convert libsigc++-2.0 for multiarch" [Wishlist,New] https://launchpad.net/bugs/900421 [03:05] the glibmm one will come in a few minutes [03:06] ..oh, ugh. glibmm just stopped building because...glib killed off g_thread_init? [03:06] no, moved it to a separate library [03:08] broder: ok, might take a look over the weekend if no one beats me to it [04:01] hello; my name is Matthew Godby, and I am currently diving into linux system administration and learning programming. I have the aim of becoming an Ubuntu developer, but I have a [04:01] couple of questions first [04:03] In the development of linux-based operating systems, is it more critical to know C or C++? [04:03] !ask | mgodby [04:03] mgodby: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience [04:03] It depends on where your focus is. [04:03] Generally I'd say C though. [04:04] could you give me one or two examples of advantages for each of those two languages? [04:04] Most Ubuntu development tasks are integration of code that's written elsewhere, so knowing something about shell and make is sufficient. [04:04] i think i'd recommend python as a starter language these days, though [04:04] and move to c after that [04:04] Agreed. [04:04] ah [04:04] If you're learning to program, Python is a very good place to start. [04:05] I started trying to learn Python but found it much more confusing than C [04:05] Also there is a significant amount of Ubuntu specialized code written in Python. [04:05] however, since it seems that it is a critical language, I will tackle it [04:05] (for example the Ubuntu graphicall installer is in Python) [04:06] excellent; I will look into the python tutorials suggested by the Ubuntu Wiki [04:06] I'm currently reading Ubuntu Unleashed and just finished the section "automating tasks" it taught me tons about shell scripting [04:07] alright, well thank you for your time! I will continue to work on C and learn Python as well; I appreciate the help [04:49] pitti: Uploaded KDE 4.7.3 for oneiric-proposed. It'd be nice to get it in on Friday so it can build over the weekend when things are usually quieter. [05:10] Good morning [05:10] ScottK: ack [05:17] is it that time already. oh [05:39] bdmurray: I would send it to debian-installer first [05:39] bdmurray: (the missing firmware on alternate issue) [07:13] pitti, yet another morning of having beer for breakfast! [07:15] rickspencer3: hehe [07:15] rickspencer3: I'm like a hawk on this now [07:15] :) [07:15] rickspencer3: and so is jenkins, we have jenkins reports for this and {archive,priority}-mismatches [07:15] I saw that one [07:16] today's alternates ought to fix the oem test failures [07:16] (currently yellow) [07:16] so we are pretty much down to fixing upgrades now [07:16] that's now our top priority [07:19] infinity: committed your d-i changes to bzr [07:20] * pitti uploads another d-i to play whack-a-omap4-abi [07:25] hi guys [07:51] pitti: d-i still seems a bit confused on armhf anyway. I need to do some debugging tomorrow. [07:54] infinity: and it failed to build, just filed bug 902051 about it [07:54] Launchpad bug 902051 in utouch-frame (Ubuntu Precise) "libutouch-frame1-udeb 2.0.0-0ubuntu1 causes d-i FTBFS" [High,New] https://launchpad.net/bugs/902051 [07:54] cjwatson: ^ I'm afraid I need your advice here; does d-i somehow blacklist/prevent libstdc++6? [07:56] pitti: There's no libstdc++-udeb. [07:56] pitti: udebs can't depend on normal debs. [07:56] oh [07:56] thanks [07:58] infinity: I'll bug cnd then [07:58] (And I'm not sure that bloating the installer with C++ is sane) [07:58] agreed [07:58] I wonder why we need a touch udeb in a text-based installer in the first place, but I might be missing something [07:59] The udeb might be meant for ubiquity usage? [08:01] infinity: I don't claim to understand the architecture there, but ubiquity runs in a full live environment, why does it have to rely on udebs? ubiquity itself isn't one [08:02] and neither are many of its dependencies [08:02] pitti: It doesn't. It may be misguided on someone's part. [08:02] cnd: input on bug 902051 appreciated [08:02] Launchpad bug 902051 in utouch-frame (Ubuntu Precise) "libutouch-frame1-udeb 2.0.0-0ubuntu1 causes d-i FTBFS" [High,Triaged] https://launchpad.net/bugs/902051 [08:02] pitti: (ubiquity imports d-i-related sources to build itself, someone may be missing how all that works) [08:02] pitti: Or maybe we really do want a touch UI for text-based d-i. I mean, at least an on-screen keyboard would be helpful. :P [08:03] but multitouch? [08:03] Probably less helpful. [08:04] Gestures for quick navigation from combo boxes to buttons? :) [08:04] Yeah, I've got nothin'. === TeTeT_ is now known as TeTeT [08:59] jibel: FYI, filed lts->ubuntu as bug 902077, reproducing/confirming/working on fix now [08:59] Launchpad bug 902077 in libdrm (Ubuntu Precise) "lucid->precise upgrade failure due to libdrm-nouveau1a Conflicts:" [High,Triaged] https://launchpad.net/bugs/902077 [09:16] jibel: hm, I don't think it's that Conflicts:; dist-upgrade will install -1a and remove -1 just fine, must be something else; I'll dig deeper [09:25] jibel: oh, are the lts->ubuntu tests done with main/restricted only? no universe? [09:25] if so, then I know what's wrong [09:27] hm, same problem with universe; argh === zyga is now known as zyga-afk [09:46] jibel: ok, got it; the question is still interesting, though; I'll fix it for "universe enabled", but "only main" needs a quirk in release-upgrader [09:50] pitti: Ugh. Why the quirk? :/ [09:50] I hate having to have upgrader workarounds... [09:50] infinity: better ideas appreciated [09:50] infinity: we can add a Conflicts: to all of them [09:50] infinity: but that would break people who actually _use_ these drivers [09:51] even those who have universe enabled, which should be "almost everyone" [09:51] pitti: What's the actual issue? [09:51] infinity: bug 902077 has the full story [09:51] Launchpad bug 902077 in xserver-xorg-video-nouveau (Ubuntu Precise) "lucid->precise upgrade holds back X.org video drivers" [High,Triaged] https://launchpad.net/bugs/902077 [09:51] (And, actually, I run a lot of main-only systems) [09:51] infinity: in short, lucid's xserver-xorg-video-all depends on a few old drivers which went to universe [09:52] so with a "main only" system, the upgrade to precise will hold back the entire X.org stack [09:52] (with apt-get dist-upgrade) [09:52] or just fail the update (do-release-upgrade) as it can't calculate an upgrade path [09:54] I don't suppose we can question why the drivers are in universe at all? [09:55] you mean instead of killed completely? [09:55] I know it's "old hardware" and all, but it seems unclever to drop support for old video cards. [09:55] they still work, just aren't supported any more (LTS/X.org team) [09:55] or even upstream, I suppose [09:55] infinity, oh, while i see that, did you plan to work on the in-initrd drm libs issue ? [09:55] but that's a question for RAOF, bryceh, Sarvatt, or tjaalton [09:56] ogra_: As in, merge plymouth changes from Debian? [09:56] ah, debian has fixed it ? [09:56] cool ! [09:56] ogra_: Yeah, but it's a bit of an upstream re-architecting. vorlon said he'd poke at it. if he doesn't get to it, I will. [09:56] * ogra_ wasnt aware, i only had that on my issues list for precise :) [09:57] We don't really want to merge the new plymouth wholesale from Debian, could be a bit diruptive. [09:57] So, going to see if there are some simple backportable fixes to get rid of the DRM dep where it's not needed. [09:57] well, if we merge it broken, it will at least be long term broken :P [09:57] pitti: Really, the problem here is that xserver-xorg-video-all shouldn't be seeded (IMO). [09:58] pitti: But it may be too late to fix that. [09:58] ++ [09:58] infinity: if it wouldn't be seeded, there's not much point in having it, thoughh [09:58] pitti: video-all should be in universe, and we should be picking the drivers we support and putting them in platform/desktop-common. [09:58] xserver-xorg-video-all would be worth a spec for next UDS actually [09:58] it's the "set of video drivers we install by default" [09:58] infinity: but that is exactly what video-all is :) [09:58] there are many situations wehere we dont want all these drivers [09:58] pitti: We already define "stuff we install by default" as "seeded". [09:58] ogra_: you can uninstall video-all and drivers you don't need [09:59] i.e. on arm we usually want xfbdev and some usb drivers ... [09:59] infinity: that would remove the possibility of trimming them down locally, though [09:59] i. e. what ogra_ says [09:59] right now you can easily remove all but e. g. -intel [09:59] if ubuntu-desktop depends on them all, you couldn't any more [09:59] If ubuntu-desktop recommended them all, you could. [09:59] But meh. [09:59] ubuntu-desktop depends on xorg, no ? [10:00] which in turn depends on -all [10:00] ogra_: no, -all | x-x-video [10:00] or did that change (i havent looked in a while) [10:00] it's been like that for ages [10:00] ah, k [10:00] as long as you have _one_ driver installed which provides x-x-video, apt is happy [10:00] It's been like that ever since -all was done. [10:00] I believe. [10:00] I vaguely recall doing this with Daniel long ago. [10:01] but anyway, v-all is there, in lucid, and we need to deal with it [10:01] But I think it's always been a bit wrong. [10:01] infinity: and also, it's not _at all_ the problem [10:01] if ubuntu-desktop depended on them instead of video-all, we would be in the exact same situation [10:01] s/Depend/Recommend/ [10:02] either way [10:02] Really, the real problem here is that forcefully removing video drivers can break a system. [10:02] the problem is that due to the demotion, a particular driver is not available any more, and thus breaks the upgrade [10:02] Which is why dropping support is a bit nasty. [10:02] so in that situation we have two options: [10:02] - remove the driver entirely and add a conflicts: [10:02] I can think of several ways to force the removal other than dist-upgrader hacks. [10:02] - warn the user and don't upgrade, if he is using that driver [10:02] But the end solution could still be an s3 system with no video. [10:02] infinity: yes, adding Conflicts: [10:03] it's easy to remove a driver, that's what I'm going to do for -nv and -v4l [10:03] but then we don't need to have them in universe any more, we could just remove them completely [10:03] release-upgrader-python-apt is build now too, waiting in NEW - I'm excited! [10:03] what always kept me from changing it in arm is that they actually dont take up much space after all ... we disussed dropping -all in favour of a list several times in the past [10:04] but in the end you only gain a meg or two [10:04] pitti: Can't xserver-xorg (or -video-all) just conflict 'xserver-xorg-video-6'? [10:04] pitti: Surely we don't need explicit conflicts for every old driver. [10:05] infinity: x-x-core already does [10:05] well, Breaks: [10:05] that's what makes apt hold it back :) [10:05] Oh. [10:06] it rather keeps the old packages than removing/upgrading [10:06] I wonder if this is one of those cases where converting a Conflict to a Break caused problems instead of solving them. [10:06] (That used to be a Conflict...) [10:06] I'll try with a Conflict [10:07] I wonder if we can even remotely try to cleverly determine the video driver in use and warn main-only users that they need to enable universe (that, obviously, would be a dist-upgrader hack, but I'm okay with that sort of hack) [10:08] infinity: ah, indeed, that'll convince apt enough [10:08] Having a situation where the archive just plain doesn't upgrade without the dist-upgrader, though, feels wrong. :/ [10:08] infinity: those drivers are abandoned upstream, so there's really no other option than get rid of the ones that don't even build anymore, and let the xserver use a fallback driver (fbdev or vesa) [10:08] tjaalton: so should we remove the lot from the archive instead of keeping it in universe? [10:09] pitti: it was a plan yes [10:09] infinity: thanks for the Breaks -> Conflicts trick [10:09] the plan [10:09] tjaalton: Oh, if fbdev and/or vesa are guaranteed to bring them back to a graphical desktop, I retract my "warn them about the situation" arguments. [10:09] mvo: so, much easier then [10:09] infinity: well, depends if the kernel even boots :) [10:09] :P [10:09] those are for really old hw [10:10] I had an i686 system with an s3virge. [10:10] I think. [10:10] with pae ? :) [10:10] Possibly an i128 too. [10:10] pitti: indeed [10:10] tjaalton: are you ok with promoting the Breaks: to Conflicts:, to tell apt to actually go and do remove the old drivers instead of holding them back? [10:11] tjaalton: (I can do the upload, just want to check if the breaks: was deliberate) [10:11] pitti: haven't read the bug or the backlog in detail yet, lunch in 5min :) [10:11] I'd have to re-read the Breaks code, and/or the policy description, but I suspect that Breaks on virtual packages (as opposed to versioned Breaks on real packages) will never really do what you were hoping. [10:12] Cause we'll want to deconfigure the virtual provider, hoping for an upgrade to come along and fix it, and no upgrade will happen. [10:12] And no guarantee of an upgrade (or even a hint at one), because it can't be versioned. [10:12] but i think this is an issue that debian has had too, I'll ask [10:13] pitti: My gut feeling would be to move all the virtuals out of xserver-xorg-core's breaks line and make them conflicts, and leave the versionable breaks on real packages in the Breaks line. [10:13] (And make sure they're versioned) [10:14] infinity: yes, that's pretty much what I just successfully tested [10:16] tjaalton: so do you want to dwell on this a bit, or should I upload this? [10:28] pitti (or anyone else): is there a nice way to determine the installed size of a package? [10:29] jamespage, apt-cache show |grep Installed [10:30] (thats in kilobytes i think) [10:31] hi all [10:32] * apw looks for an AA to stroke the ti-omap4 kernel through on precise [10:35] ogra_, thanks - just what I was looking for [10:41] pitti: yeah it needs to be pushed to git anyway [10:48] apw: I may have already done it while you were asking who to ask. [10:50] infinity, thanks :) [10:50] (cd conf && patch < ../debian/as-needed.patch) [10:50] patching file ltmain.sh [10:50] Hunk #1 succeeded at 5512 (offset 12 lines). [10:50] Hunk #2 FAILED at 6155. [10:50] 1 out of 2 hunks FAILED -- saving rejects to file ltmain.sh.rej [10:51] ^--- Dear god, how many of these do we have in the archive? [10:53] doko: libdap needs as-needed patch unbuggering. I'm going back to bed. ;) [10:56] infinity: we already fix that (in Debian) [10:57] fixed [10:57] -10 can be synced when LP learns of it [10:57] pitti, infinity: debian-x doesn't like the change, instead conflicts should be added for just drivers that are gone [11:00] tjaalton: Hrm. They do realise that breaks on virtual packages are kinda meaningless, right? [11:03] infinity: apparently it works just fine, as long as there is an installable candidate that fulfills the dependency [11:03] so for packages that are no more conflicts should be used [11:04] tjaalton: But the virtual is no more... [11:04] * infinity gives up. [11:04] hehe [11:04] Laney: Thanks for the tip, synced. [11:06] huh, that was fast [11:06] or did you do a manual sync? [11:06] Sync from incoming. Magic. [11:06] HAX [11:07] It unsnags a long armhf dep chain, I'm impatient. :) [11:07] dh_autoreconf --as-needed is a blessing [11:20] meh, can someone moderate my message to ubuntu-app-devel? === _salem is now known as salem_ [11:32] infinity, pitti: I'll upload with the changes you proposed, plus added -nv and -v4l in conflicts [11:32] believe it's the only sane way to fix it for the case where universe is not used [11:48] tjaalton: if you turn the Breaks: video-6 into a Conflicts:, you don't need to special-case -nv and -v4l [11:49] tjaalton: these two will be removed with universe, and the 8 or so without universe [11:49] tjaalton: I tried this, works fine [11:50] tjaalton: ah, you already uploaded, thanks! so, the two extra conflicts: don't hurt, that's fine [11:53] RAOF: uploaded a new policykit package which contains the owner patch. [11:53] (to Debian i.e. but I assume it will be synced soon) [11:53] RAOF: you can update colord now [11:54] mbiebl, RAOF: synced polkit, thanks Michael [11:57] well, thanks RAOF for getting this patch/functionality into upstream :-) [12:09] tseliot: did you see https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/873058/comments/18 ? [12:09] Ubuntu bug 873058 in nvidia-common (Ubuntu Oneiric) "Jockey fail to install binary ati driver (post release) version" [High,In progress] [12:15] pitti: not yet, I'll have a look at it soon, thanks [12:15] * tseliot -> lunch === ara is now known as Guest31779 [12:19] pitti: hm, got the reject messages for policykit-1 [12:19] does the ubuntu archive not yet support the introspection section? [12:19] mbiebl: uh, which? [12:19] ah, I guess not [12:20] mbiebl: I'll ask around how to get it [12:20] http://paste.debian.net/148710/ [12:22] yep, it's also in the build log, https://launchpadlibrarian.net/87079157/upload_3145846_log.txt [12:23] mbiebl: filed as bug 902130, asking LP now [12:23] Launchpad bug 902130 in Launchpad itself "Need to add allowed section "introspection" for ubuntu packages" [Undecided,New] https://launchpad.net/bugs/902130 [12:24] pitti: you already have metapackages, I guess? [12:24] that the other new section that was added to Debian recently [12:24] mbiebl: yes, we've got that pretty much forever [12:24] and "translations" [12:24] :-) [12:30] pitti: here is the announcement http://lists.debian.org/debian-devel/2011/12/msg00051.html [12:31] mbiebl: thanks [12:31] seems I missed education [12:31] and some packages already started using it [12:35] mbiebl: seems fixed :) I'll retry the build, thanks for pointing out! [12:35] heh, that was quick [12:37] indeed! [12:37] err.. https://launchpadlibrarian.net/87079108/buildlog_ubuntu-precise-armhf.policykit-1_0.103-1_FAILEDTOBUILD.txt.gz [12:37] unknown Debian architecture armhf, you must specify GNU system type, too at /usr/bin/dpkg-architecture line 144. [12:37] doko, infinity ^ do you see what's wrong there? [12:38] pitti: That buildd needs an lp-buildd upgrade. [12:38] pitti: yeah at least it's more "detailed" as it is now [12:38] pitti: And that package actually lists armhf in its Arch line, which is rare. [12:39] Wait. [12:39] why would it do that ? [12:39] Which machine is that? [12:39] shoulodnt it just be any ? [12:39] SONOFA. [12:39] genip [12:39] pitti: yeah. Fixing. [12:39] Not happy. [12:39] Who keeps moving them? :/ [12:40] infinity: (feel free to request a global upgrade next week if you want) [12:40] infinity: where do you see the explicit armhf in architecture:? I dont' see it in debian/control [12:40] they are all "any" or "all" [12:40] infinity: thanks for fixing [12:41] pitti: linux-any is explicit, from the POV of sbuild. [12:41] pitti: Anyhow, genip is back to armel again, that build won't have the same explosion. [12:41] ah [12:42] And "any all" is also explicit. Sort of. [12:42] ♪ it's a kind of maagiiiiic ♬ ♩ [12:42] wgrant: Yeah, I was going to do it this week, but armel was chugging away on seriously long builds. [12:42] Though, it doesn't seem like a terribly harmful Friday thing, given that it's well-tested in production. [12:56] stgraber, parti-all was removed in debian, should it still stay in precise? ftbfs on armhf, likely on other archs [13:03] stgraber, I'm told this is replaced by xpra, and should be removed? === asac is now known as asac_the_enginee === zyga-afk is now known as zyga [13:28] hello [13:55] pitti: Would you please also have a look at soprano with 4.7.3 as it goes with it. [13:55] ScottK: yes, getting there [13:56] pitti: OK. No rush, just wanted to make sure it wasn't forgotten. [13:56] Thanks. [13:59] doko: it's a bit weird at the moment, I see both parti-all and xpra in the archive, probably both building python-xpra. The former has some patches I made for it, the later doesn't. [13:59] stgraber, right, but parti-all ftbfs [13:59] doko: So I guess we can also remove parti-all and just re-apply the patches on xpra [14:00] infinity, https://launchpadlibrarian.net/87085147/buildlog_ubuntu-precise-armhf.happy_1.18.6-1_MANUALDEPWAIT.txt.gz needs a bootstrap build [14:00] they were minimal patches, just changing a default flag on the X server and another changing the default framebuffer resolution, so I can easily re-apply them to the new source package [14:01] (still need to poke upstream about these, they're not really Ubuntu specific so may be suitable there, if they agree with these defaults too) [14:01] hallyn, thank you for the nested container info. [14:03] Has the autosyncer from debian been launched during the last few days? I can't find some packages recently appeared in testing. [14:05] autosyncer doesn't sync new packages [14:05] that's a manual process [14:06] ah, so should I file a sync request for those? [14:06] DktrKranz: no, it's still done in bulk [14:06] but it's a separate action / process [14:07] DktrKranz: just poke today's archive admin [14:07] (sorry, I have about 10 things to finish in the next two hours, can't do it now) [14:08] np, thanks for the info [14:10] stgraber, https://launchpad.net/ubuntu/+source/xpra/0.0.7.30+dfsg-1/+build/2969603 built fine. so maybe drop parti-all, or fix the ftbfs === asac_the_enginee is now known as asac_the_boss === asac_the_boss is now known as asac_the_2nd [14:21] asac_the_engine? [14:22] haha [14:22] doko: thats also tryue ... but i ment the engineer :) [14:22] now i am the king again [14:22] asac_the_geraet :P === arges_home is now known as arges [14:26] doko: ok, can you remove parti-all from the archive? I'll deal with applying the patches to xpra when I have some time (not having them won't break anything, just won't be as secure and will be a bit weird on dual-head setups) [14:40] stgraber, done [14:40] doko: thanks === MacSlow is now known as MacSlow|lunch === asac_the_2nd is now known as asac [14:54] jelmer, still ftbfs on armhf, see https://launchpad.net/ubuntu/+source/bzr/2.5.0~beta4-1ubuntu1/+build/2994205. any idea? [14:58] doko: argh, that's yet another one. Filed bug #902182 [14:58] Launchpad bug 902182 in bzr (Ubuntu) "spurious failure of test_readv_with_adjust_for_latency(HttpTransport_urllib,HTTPSServer_urllib) on armhf" [High,Triaged] https://launchpad.net/bugs/902182 === ara_ is now known as ara [15:03] cjwatson: I'm trying to get gparted and dmraid resynced with debian... doing so requires the corresponding patch to parted ( dm_p_seperator.patch ). Do you think you could upload that to debian if themuso uploads dmraid? [15:14] smoser: np, i'm going to fix the cgroup thing today, the network of course is same as with qemu, nothing to be done about it [15:15] hallyn, i assume, though, that you were testing those rarely used tools [15:15] (ie, not libvirt ;) === zyga is now known as zyga-afk [15:17] i ask because in the target case, we'd be using juju->localprovider (which uses lxc package), and inside the localprovider's containers we'd have nova-compute, which is going to use libvirt-lxc [15:19] i wasn't using juju or libvirt. I was using lxc in precise which has its own bridge [15:19] libvirt's bridge, just like lxc's, can't be used nested without changingn the address for the nested virbr0 === yofel_ is now known as yofel === zyga-afk is now known as zygaq === zygaq is now known as zyga [15:46] gilir: hello Julien, how are you? [15:46] gilir: do you particularly care about awn-extras? [15:47] hi pitti [15:47] pitti, euh yes, but I know I need to fix a couple of things on awn-extras and some of its depends [15:47] gilir: I tried to build it against current precise, and it fails in multiple ways; several plugins get disabled now as the libs changed, etc. [15:48] so before I spend more hours on it I wondered if you already have something in some git tree [15:48] pitti, yes, it's in a pretty bad shape currently [15:49] vala-awn is gone, it's in libawn-dev now; that part works at least [15:49] pitti, yes, I can work on it this week-end, I have already some fixes on my system [15:49] oh, good [15:49] pitti, I'm taking a look at bug 902051 now [15:49] Launchpad bug 902051 in utouch-frame (Ubuntu Precise) "libutouch-frame1-udeb 2.0.0-0ubuntu1 causes d-i FTBFS" [High,Triaged] https://launchpad.net/bugs/902051 [15:49] cnd: good morning! thanks, appreciated [15:49] gilir: so maybe we can sync up next week and see what's left, and I might be able to give a hand [15:51] pitti, ok thanks :) [15:51] pitti, the udeb will go away in precise, but is still needed for now [15:51] but only the utouch-frame 1.x functionality [15:52] cnd: any chance to build it without C++ then? [15:52] so I just need to figure out how to strip out the utouch-frame 2.x stuff for the udeb [15:52] if it goes away anyway, I guess it's not worth changing gcc to build a listdc++ udeb [15:52] yeah, it's definitely something we should fix in utouch-frame for now [15:54] Riddell, please update the opengtl symbols file for armhf [15:54] doko: ok, on the todo list [15:54] thanks [15:56] pitti, would you by any chance now how to delete symbols from an so? [15:56] that would be the easiest solution :) [15:56] cnd: you mean from a binary? no [15:57] hmm, ok [15:57] cnd: I think you'd need to do a multi-build, and disable the 2.0 parts in the build-udeb/ tree [15:57] that's the usual way of doing things like taht [15:57] yeah [15:57] cnd: this is actually a single .so? [15:58] I'm just trying to find the easiest way for now [15:58] yeah [15:58] cnd: if it's separate ELF files in one package, you can do it more easily [15:58] it's a single .so.1 with both 1.x and 2.x symbols [15:58] once we've transitioned everything in ubuntu off of the 1.x symbols we'll bump it to .so.2 and remove the old stuff [15:59] so, I think multi-build is the best option here; hacking the .so doesn't sound any easier and robust TBH [15:59] ok [15:59] pitti, got any examples off the top of your head that I could look at? [16:01] udev [16:01] ok [16:01] cnd: basically, in build: you mkdir build-deb/ build-udeb, then for each variant cd into the build dir and ../configure [...] [16:02] to get two independent out-of-tree builds [16:02] alright [16:05] cjwatson: do you have a sec to look at bug 897880 and check if my reasoning is correct? I'm not able to reproduce the problem, but I think I know why it fails [16:05] Launchpad bug 897880 in doc-base (Ubuntu Precise) "package doc-base 0.10.3 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 127" [High,In progress] https://launchpad.net/bugs/897880 [16:06] tjaalton: http://old.nabble.com/-PATCH--Add-support-for-Lenovo-tablet-ID-0xE6-td31294086.html Do you know what became of that? [16:09] cjwatson: ah, unping; perl 5.14.2-6 does exactly what I proposed in the bug, so I'll merge that [16:10] cjwatson: in fact, we can sync [16:12] jibel: bug 897880 should be nailed now as well [16:12] Launchpad bug 897880 in perl (Ubuntu Precise) "package doc-base 0.10.3 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 127" [High,Fix released] https://launchpad.net/bugs/897880 [16:12] jibel: that was another major upgrade breaker [16:13] edgy: qemu-kvm-spice package in precise should work [16:13] pitti, cool. I re-ran the upgrades with u-m from bzr [16:13]