[00:31] cyphermox: I'm looking at bluez and trying to figure out why it depends on python-gobject? AFAICT from grepping the code python-gobject is only used in the tests. I'm asking because it's pulling python-gobject and another stack of things into the kubuntu seeds. === lamont` is now known as lamont [01:55] ScottK: ok. well, I'll be happy to drop it if it's possible. I'm about to do an upload; I can check now [01:55] cyphermox: Thanks. [01:56] ah, I see [01:56] ScottK: I kind of like having these "tests" around; though maybe they'd be better suited in a separate package [01:57] That or ship the tests, but drop python-gobject to Suggests. [01:57] I think for tests that aren't automatically run, that's reasonable. [01:58] ScottK: those things really attempt to give you information about bluetooth devices more than actually being tests, but I think that's reasonable still [02:08] ScottK: did you file a bug about this? [02:10] cyphermox: No. [02:10] ok [02:29] isn't dh_translations supposed to remove the .mo files from the package and put them in the langpack isntead? [02:47] cyphermox: it would have been nice to document reason for the drop to suggests in bluez in a bug or in the changelog itself [03:05] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell, pitti [03:05] psusi: no, that's the job of pkgbinarymangler [03:10] slangasek, ohh... so when I build the binary package, the .mo files are still there, but when it hits the archive, they get stripped? [03:10] psusi: pkgbinarymangler is installed in the build chroots on the Ubuntu buildds, and strips them out as part of the package build [03:11] I see [03:11] (by diverting/wrapping the commands used for building, making it transparent to the actual package) [03:12] you can do the same locally with a properly configured sbuild (and probably pbuilder as well) [04:07] Hello [05:45] Good morning [05:45] cjwatson: waiting for micahg; I asked yesterday, not sure about the current status [05:45] ev: StacktraceAddressSignature is many to one [05:46] ev: in practice, I found that > 90% of our bugs in the db just have one address signature, but some have 5, and one had 10 [05:46] SpamapS: ah, yes [05:46] @pilot out === udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell [06:41] raof, hi, current drm-intel-next has basically the same problems [06:41] poolie: :( [06:42] i guess i could try digging in to that part of the kernel [06:42] Now, I've dropped context. What was the problem, again? Was it “VT-d makes my system crazyslow?” [06:42] ah, that actually is adequately worked around by turning it off [06:43] i guess ideally the kernel would cope if it was turned on [06:43] no, this is bug 745112 (sorry for not quoting that) - external monitors can't reliably be set above about 1280x1024 [06:43] Launchpad bug 745112 in linux (Ubuntu) "[arrandale] desktop is messed up with external monitors (x86_64)" [Critical,Triaged] https://launchpad.net/bugs/745112 [06:52] poolie: Urgh. Time to upstream that bug. [07:10] Riddell, ScottK: do you know why calligra-libs Conflicts: koffice-libs? that seems to be the main reason for the uninstallability (http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html) [07:41] poolie: would you mind opening a bugreport either on the kernel or fdo bugzilla? I can walk you through it [07:42] tjaalton, sure, just tell me where [07:42] can lp send it upstream or should i create it manually? [07:42] don't think it can [07:42] but, you can comment on the upstream bug via lp [07:43] so if you don't have an account on fdo I could open the bug and you could interact with it via lp [07:45] i think i have one - should it be there or on the kernel? [07:45] either works, but I think the fdo one is used more [07:45] hang on [07:47] of course bugs.fd.o seems to be down atm [07:52] good morning === tkamppeter_ is now known as tkamppeter [07:57] poolie: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg then select Driver/intel [08:00] poolie: actually, scratch that [08:00] (otp) [08:00] but let me know [08:02] poolie: as it's likely a bug in the drm driver, use https://bugs.freedesktop.org/enter_bug.cgi?product=DRI and DRM/Intel [08:12] poolie: here's a list of what information upstream would like on the bugreport http://intellinuxgraphics.org/how_to_report_bug.html [08:16] what is the meaning of putting {python:Depends} in a control file rather than just 'python'? [08:17] it's a variable that gets replaced with the correct dependency on python itself === smb` is now known as smb [08:45] shouldn't /usr/include/$triplet/ be in the default search path for headers? [08:47] because I get this http://pastebin.com/JN3JpCUU [08:47] the headers are in /usr/include/$triplet/bits/* [08:55] well, nothing under /usr/include/$triplet/ is found [09:02] tjaalton, that rings a bell with me, but i think it's meant to be set outside of gcc... [09:03] can't remember where [09:03] yeah googling revealed similar issues [09:03] fixed by patching the source.. [09:05] tjaalton: if I read the MultiArch pages correctly then /usr/include isn't multi-arched yet [09:06] geser: ref? [09:08] tjaalton: http://wiki.debian.org/Multiarch/Implementation, section "What does the end result look like?" [09:08] and two points above that header: "If your -dev package contains headers which vary across architectures then it cannot be marked as Multi-Arch: same until a policy decision is made about architecture-dependant headers and the toolchain is updated." [09:08] hmm ok [09:10] tjaalton, ok https://bugs.freedesktop.org/show_bug.cgi?id=45211 [09:10] Freedesktop bug 45211 in DRM/Intel "[arrandale] blank external monitor at high resolution" [Normal,New: ] [09:11] poolie: excellent, thanks [09:11] do you know what project i use in lp to attach to that bug? [09:11] just did that [09:12] there was already xf86-video-intel "opened" for it [09:12] huh [09:12] just mentioning it is enough? [09:14] with the upstream url [09:14] but it's there now [09:17] doko_: is it a mistake or intentional that bits/ etc are under /usr/include/$triplet/bits etc? [09:25] tjaalton, surely they are platform-specific, by definition? [09:25] libc6-dev-i386 installs into /usr/include/sys/? [09:25] on amd64 [09:25] i'm just confused by all this .) [09:26] :) [09:26] point is that /usr/include/features.h can't find it's headers [09:26] looking at packages.ubuntu.com, libc6-dev installs some files to /usr/include/$triplet since oneiric [09:26] and the fix can't be to install the i386 dev package [09:26] geser: right [09:27] tjaalton, i know it looks like it installs there, but it's actually redirected [09:27] (may not actually be a 'redirect') [09:27] lrwxrwxrwx 1 root 29 Jan 24 04:03 /usr/include/sys/sem.h -> ../x86_64-linux-gnu/sys/sem.h [09:28] hm? which package created the symlink then? [09:30] sorry i can't remember where this is configured [09:30] but, there is a thing, that allows two packages to both try to install to the same place, and they get moved [09:30] and that's what's happening here [09:30] anyhow, that's it for me, good night [09:30] ok, it's gcc-multilib [09:31] installed it and now I have a symlink from /usr/include/bits -> $triplet/bits [09:31] poolie: sounds like a diversion [09:31] doko_: nevermind :) [09:32] that's the word i was trying to remember, thanks [09:32] another mesa build then.. [09:33] pitti: cheers === ara is now known as Guest18025 [10:00] pitti: koffice is due to be deleted but I'm busy on the KDE SC release this week so I stopped working on koffice/calligra for immediately [10:01] Riddell: ah, ok; so will calligra grow some extra transitional packages for this then? [10:04] Riddell: thanks for the heads-up [10:14] pitti: I need to look at having a smooth upgrade, maybe some transitional packages will be appropriate (it's a bit political since koffice still exists as a project) === zyga-afk is now known as zyga === mpt_ is now known as mpt [10:43] kirkland, hey [10:43] Jan 25 10:57:26 localhost kernel: [ 3201.475561] Valid eCryptfs headers not foun [10:43] d in file header region or xattr region [10:43] Jan 25 10:57:26 localhost kernel: [ 3201.475564] Either the lower file is not in [10:43] a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrou [10:43] gh mode is not enabled; returning -EIO [10:43] kirkland, is that a known issue? those are filing my kern.log [10:43] kirkland: ^ FWIW, I get these all the time [10:43] I don't notice anything which actually goes wrong [10:44] tjaalton, wondering why you would need gcc-multilib at all ... [10:48] doko_: I don't have /usr/include/{sys,bits} etc without it, dunno if it's a bug then [10:50] tjaalton, it should not be a bug, because it should fine the bits in /usr/include/ [10:50] what is the error? [10:50] doko_: http://pastebin.com/JN3JpCUU [10:51] tjaalton, and makedepend is aware of multiarch? [10:51] $ dpkg -S predefs.h [10:51] libc6-dev: /usr/include/x86_64-linux-gnu/bits/predefs.h [10:52] well, rest of mesa is [10:52] dunno if it needs a hammer === _salem is now known as salem_ [10:56] tjaalton, does mesa build 32bit binaries on amd64? [10:57] doko_: not that I know of [10:57] hmm [10:58] but that doesn't mean much ;) [10:59] it builds a bunch of libs, that's pretty much it [10:59] mesa doesn't build a lib32something binary package anyway [11:14] Mez: it goes back a long time it eems [11:14] err [11:45] pitti: No. Riddell did all the Calligra stuff, although I'm not surprised they aren't co-installable - this is similar to the OOo -> LO migration. [11:47] s/did/is still in the process of/ since it's paused while I do KDE SC 4.8 :) [11:52] they are not coinstallable [11:52] at least not in the .mo level [11:52] they clash like crazy === doko_ is now known as doko === MacSlow is now known as MacSlow|lunch === sagaci_ is now known as sagaci [12:31] Daviey: bind9 uploaded to debian, will sync it once sid has it [12:33] lamont: that is great! Thanks for the fast response. When you sync, can you close the ubuntu bug aswell? :) [12:34] will do so [12:50] infinity: [adconrad] Co-ordinate the porting of ocaml-opt to armhf: TODO [12:51] infinity: I think this is more or less done now; doko enabled it in ocaml itself a while back, and I got irritated by the stack of failures and went through and reuploaded nearly everything relevant earlier this week [12:51] heh [12:51] infinity: I only just noticed the work item [12:52] infinity: the only thing left is (a) coq and its reverse-build-deps (coq fails to build for some reason); (b) doing another sanity-comparison of cmx entries between armel and armhf Contents files, after LP next sees fit to regenerate them [12:52] it was mostly just a matter of rebuilding everything in dependency order [12:55] hmm, did I leave something half-finished? [13:01] doko: findlib had to be rebuilt to be aware that ocamlopt was available, and then everything that might have been able to build with ocamlopt had to be rebuilt [13:01] doko: I only worked that out by inspection of build failures and some pondering though [13:27] HI guys How to build deb package from source please guide me. guys [13:28] debuild [13:29] silly(?) question - it seems now we have sudo and admin groups. but users are not auto-transitioned, is that correct? [13:31] correct [13:32] mvo: we went through some effort to teach packages to get along with either [13:32] it's not entirely clear what we should ultimately do there but at the moment apps need to check both [13:32] auto-transitioning in u-m might be worthwhile; is there not a bug about that, actually? [13:32] aptdaemon uses root.admin currently for sources.list entries with private tokens [13:33] so either that needs to become root.sudo [13:33] jockey has the same problem, but I could get around that as it's only a first-time install matter there, so I switched to sudo [13:34] * mvo scratches head [13:35] HI guys How to build deb package from source please guide me. guys [13:35] debuild [13:35] as colin said above already [13:35] read zthe manpage [13:35] *the [13:36] !packaging guide [13:36] The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports [13:47] How to automate package creation from source. [13:53] pitti: hoping to finish the testing today, lucid is almost done, but I figure that we don't want to break upgrades [13:54] micahg: good morning; ah, thanks! [13:59] I'm trying to multi-arch libidl0, it depends on cpp, which means the i386 package still won't install on amd64, needs cpp:i386... does that mean cpp needs multi-arching? [14:02] dhana013: you can't [14:03] dhana013: or maybe I should answer "pay canonical" :) [14:04] you can, if you know how to set up a buildd :) [14:04] or how to write PPA build reciepes [14:05] yeah once you do the initial packaging there's ways to automate updates [14:05] generally speaking, automating packaging doesn't work so well. But automated updates (like the daily build recipes) do work rather well === MacSlow|lunch is now known as MacSlow [14:05] and ways to help the initial packaging too but that's never anything like 100% automatic [14:05] alien ftw ! [14:05] * ogra_ hides :) [14:05] :) [14:10] TREllis: Multi-Arch: foreign on cpp *might* be the right thing if the version from another architecture will work; but I would have thought that cpp has architecture-specific defaults in it ... [14:10] TREllis: we don't have provision for real multi-arch of binaries yet [14:12] lamont/buildd admins: I just gave back a timed out pypy build and it went back to the same builder, yellow. If you can kill it, I can try giving it back when yellow is otherwise occupied [14:12] tumbleweed: that's not actually solving the problem [14:12] no, I'm interested in ideas for that :) [14:12] I thought my memory check was sufficient, but it appears not to be [14:12] cjwatson: right I thought that might be the case. That's one of my blockers at the moment whilst trying to fix a chain of multi-arch dependancies [14:13] if that was the build that was driving yellow into the ground with it's memory footprint, I suspect that it needs to be less agressive in its total vm footprint, probably a test suite of the "hey, this'll fit, I think" variety [14:14] yellow has 4GB of RAM and 4.5GB of swap [14:14] it's checking MemTotal in meminfo [14:14] and it had 42% swap free a while ago [14:14] ok, I didn't do any emprical checking on amd64, but I did check that it would build on i386 with 1.7G RAM (everything else mlocked) [14:14] and the check doubles that for 64bit [14:16] lamont: I'll try an allocation test in the next upload [14:17] WebKitGtk+ is still lacking access to DOM events in 1.7. Does anyone know what the consensus approach for communicating with a WebKit WebView is? Please say something other than "multiplexing the title element." :) [14:17] in GI, that is [14:24] Riddell, then How to create custom distro based on ubuntu but not dependent with ubuntu repo. [14:25] How to create custom distro based on ubuntu, but not dependent with ubuntu repo. [14:25] dhana013: umm that's a different question, see https://help.ubuntu.com/community/LiveCDCustomization or "pay canonical" [14:25] could you please stop repeating yourself all the time ? [14:26] asking once is sufficient [14:29] I can't pay canonical I want to make source build to my custom distro is possible, all packages i can convert to my distro it's possible [14:33] ev: are those bits in the .gir but just have introspectable="0" on them? [14:34] dobey: correct [14:35] I just found this from sil, which leads me to believe that document.title is still the only game in town http://askubuntu.com/a/97682/46 [14:36] ev: i think the answer is you need to fix webkit so the APIs are introspectable. i am not sure what that entails exactly, beyond tweaks to the documentation in the C code. [14:37] I'd love to have the time for that [14:37] yeah [14:37] * dobey also wants the vapi to get updated for vala === yofel_ is now known as yofel [15:04] can somebody please massage my mail through u-d-a? === mpt_ is now known as mpt [15:16] how do I make sed apply to only the first line of a file? [15:20] Riddell: sed '1 s/foo/bar/' [15:20] Riddell: you can specify a line number or a range [15:21] e. g. 1,3 for the first three lines [15:24] cool thanks pitti [15:25] cnd: your latest update of x11proto-input-dev has reverted multiarch support; is there a vcs repo somewhere that you're maintaining this package? (Not listed in debian/control) [15:32] thanks for moderating it through [15:36] * smb silently curses about non-obvious server disconnects [15:36] slangasek, While looking at bug 607039 again, I realized that this actually has been fixed by an update to 662711. I assume the best action for the former is to mark it a duplicate of the latter bug then. Probably bug 117957 can either be closed marked duplicate, too. Not sure which as that has a debian bug reference. [15:36] Launchpad bug 607039 in nfs-utils (Ubuntu) "NFS4 automount using replicated servers doesn't work" [Medium,New] https://launchpad.net/bugs/607039 [15:36] Launchpad bug 117957 in nfs-utils (Ubuntu) "Need to modprobe nfs module before mounting nfs4 export" [Medium,Triaged] https://launchpad.net/bugs/117957 [15:36] ScottK: the pyqt4 stuff looks good. i'm just doing a chroot install check and if that pans out, i'll do the upload. thanks for fixing this. i'm also going to look at sync'ing pydbus today [15:36] slangasek, Do you think that change is worth a backport to Oneiric, still? [15:36] barry: Cool. [15:41] smb: hmm, don't we still need to fix the module aliasing somewhere here? [15:42] I wouldn't expect idmapd to magically autoload the nfs kernel module, but maybe I'm mistaken [15:42] slangasek, Well I'd have something for that, but practically when you did always modprobe nfs with idmap and always start idmapo now as the bug fix [15:43] + should always be started automatically, because we can no longer assume [15:43] + that a mount of type 'nfs' in /etc/fstab is not nfs4. This also lets [15:43] + things work by default with nfs4 autofs. LP: #662711 [15:43] smb: oh, because the idmap job explicitly modprobes nfs, right [15:43] yup [15:44] I'm not sure if we should backport that to oneiric. what's your opinion? [15:45] slangasek, So fwiw nfs module always is already loaded when you try to mount, which makes the modprobe for nfs4 just silently fail but not necessary. [15:46] slangasek, Hm, the problem is there too. And the fact that lead to modprobe it in idmapd upstart would be as valid there. [15:46] (not that ANY reporter gets back to you as soon as they now a manual workaround) [15:46] has anyone seen voidspace around here lately? [15:47] slangasek, Guess given that, we could just cover our eyes and wait until someone shouts at us [15:48] smb: :) well, I think if you want to do the work to backport the change, it would be an acceptable SRU - so it's up to you whether you think it's worth the effort === jml is now known as jml` === mbiebl_ is now known as mbiebl === jml` is now known as jml [15:51] ScottK: a few lintian warnings on the resulting .debs, but i think i can fix them: http://pastebin.ubuntu.com/816583/ [15:52] barry: Sounds good. [15:52] Thanks. [15:52] slangasek, Given it is some work to touch the package, and that one can easily work around it by having the modprobe.d alias (as documented in the first bug), I think it is maybe not worth doing as long someone really persists. At least it is ok in Precise. [15:53] ok [15:58] slangasek, So what would you think I should do with that very old bug report #117957. Also mark it a duplicate of the other. Or just close it fixed with a note to the other bug? [15:59] smb: I wouldn't mark it as a duplicate, but I think it can be closed [15:59] (with a note) [15:59] slangasek, ok, will do === bdmurray_ is now known as bdmurray === synack is now known as Guest42724 === ogasawara is now known as Guest1558 === jackyalcine is now known as Guest1073 [16:09] make[2]: Entering directory `/tmp/gcc/test/eglibc-2.13' [16:09] /usr/bin/install -c -m 644 include/limits.h /usr/include/limits.h [16:09] does someone had similar attempt during (cross) build of eglibc? === ikonia_ is now known as ikonia === Ursinha` is now known as Ursinha === mpt_ is now known as mpt === SpamapS_ is now known as SpamapS === james_w` is now known as james_w [16:47] kirkland`, hi, is now a good time to talk settings? === kalosaurusrex is now known as albrigha === deryck is now known as deryck[lunch] [17:49] cjwatson: Ahh, didn't realise it was just findlib having a hissy fit. Thanks for the catch. [17:56] ScottK: i'm giving up on the executable-not-elf-or-script lintian warnings in python-qt4-doc. dh_fixperms does seem to be getting called, but it doesn't remove the x bit from the files (even when called manually with other cli options). i did fix the strip problem though, so... [17:56] bdmurray: You just added a rls-mgr-p-tracking tag to Bug 651294. That bug is fixed, so I don't think that's what we want. [17:56] Launchpad bug 651294 in xorg-server (Ubuntu Maverick) "X crash on KDM logout (still - yes, really)" [High,Confirmed] https://launchpad.net/bugs/651294 [17:56] barry: I think the strip problem was the most important. [17:56] ScottK: agred [17:56] ScottK: the latest comments indicate otherwise [17:57] ScottK: feel free to remove it though === Guest42724 is now known as synack [17:57] bdmurray: No. That bug was fixed. Someone is having similar symptoms. They should file a new bug and not try to go back and comment on ones that are already closed. [17:57] ScottK: well you could say as much in the bug report [17:57] I did. [17:58] bdmurray: ~ one minute before you added the tag, [17:58] So it's just a timing issue. [17:58] I'll remove it. [17:59] Done. Thaks. [17:59] Thanks even. [18:02] barry: Nice job on the dbus stuff, dbus-python and python-qt4. Thanks. [18:02] ScottK: thanks. i'm looking at pulling dbus-python 1.0.0 from debian now. it'll be nice to resync [18:03] debian experimental [18:03] Right. Once it's built on experimental for i386, I can push the python-qt4 changes back to experimental and we can sync from there. [18:04] +1 [18:25] barry: I mashed retry on armhf. It was a very odd error like the builder vanished out from under it. [18:25] maybe it ran out of memory? === beuno_ is now known as beuno === deryck[lunch] is now known as deryck [18:44] cjwatson: got a sec? [18:50] has anybody tried to build totem-3.3.4 ? [18:51] wolter, it's in https://launchpad.net/~gnome3-team/+archive/gnome3 [18:52] wolter, that's an unstable ppa though so not really recommended for use if you want a stable system (but totem 3.3 is unstable as well so you probably don't aim at something working solid) === mpt_ is now known as mpt [18:53] seb128, yeah I just want to try it to test if a bug I reported is fixed already [18:54] Thanks for the guidance! [18:54] wolter, yw [18:55] could somebody score the builds of indicator-appmenu and unity in https://launchpad.net/~unity-team/+archive/hud/+packages ? [18:55] they need a rebuild for the precise indicator transition [18:55] doko, pitti, cjwatson: ^ [18:55] jono, kenvandine: ^ should fix things [18:56] seb128: I can do that. [18:56] infinity, thanks [18:56] seb128, what should fix things? [18:56] seb128: Err, but those are clearly PPA versions. [18:56] I disconnected [18:57] jono, could somebody score the builds of indicator-appmenu and unity in https://launchpad.net/~unity-team/+archive/hud/+packages ? [18:57] thanks seb128 [18:57] infinity, yeah, and we need those rebuild to happen earlier rather than later ;-) [18:57] libindicator got an soname update in precise [18:57] * micahg is waiting for the unity amd64 archive build :) [18:57] but ppa builder lag half a day behind [18:58] seb128: done [18:58] stgraber: Ahh, you'd be the reason I OOPSed. :P [18:59] * micahg would suggest blaming launchpad instead :) [18:59] infinity: well, no, the reason would be a bug in LP, but I certainly contributed to having that bug affect you [19:00] infinity: so LP doesn't like you trying to rescore something that's already building? :) [19:00] stgraber: Well, yes. It's a bug that when you try to rescore a build that's in the BUILDING state, it OOPSes instead of giving you a friendly message. But you helped me trigger it. Better? :P [19:02] I've got some local users breathing down my neck because appmenu is exporting UBUNTU_MENUPROXY in non-unity desktop environments. Is there any particular reason that this isn't done in the unity session only? (The related bugs all seem to be marked as duplicates of bug 787465 which is specific to gnome-terminal and fixed, according to jbicha) [19:02] Launchpad bug 787465 in gnome-terminal (Ubuntu) "View->Show MenuBar isn't working in 11.04 and later in gnome-terminal" [Undecided,Confirmed] https://launchpad.net/bugs/787465 [19:02] infinity: yep, that sounds good, now go file a bug since you were the one who got the ooops ;) [19:02] tumbleweed: isn't the appmenu stuff working with KDE too? [19:03] stgraber: neither KDE or unity [19:03] awesome, fluxbox, etc [19:23] cjwatson: nvm :) === kalosaurusrex is now known as albrigha === micahg_ is now known as micahg [20:01] cyphermox: I wouldn't bother much with libchamplain-0.8 or clutter-gtk-0.10, both need to be removed as soon as their rdeps are migrated [20:05] micahg: i know but in the meantime it works. this was a simple patch to grab from upstream and massage to apply [20:07] cyphermox: you could have just as easily merged claws-mail-extras-plugin or whatever and got it removed :), it's all good though [20:10] * micahg treats versioned source package names suspiciously [20:11] @pilot in [20:14] * micahg kicks ubottu [20:16] micahg: if you're not touching claws-mail-extras-plugin though I'll do the merge now :) [20:17] cyphermox: well, was going to leave it for barry on his +1 mission next month, so I'm not touching it, but if he doesn't mind, have at it :) [20:17] ah, I don't especially mind waiting either. Just picking at anything I can fix, really [20:18] pino has an RC bug (needs sync) and needs a g_thread_init patch to build [20:19] or update libav-extra to 4:0.8ubuntu1 (bug 921765) as I mentioned in --motu [20:19] Launchpad bug 921765 in libav-extra (Ubuntu) "libav-extra needs rebuild to >=4:0.8 so dev packages can be installed" [Undecided,New] https://launchpad.net/bugs/921765 [20:20] cyphermox: ^^ [20:22] micahg: thx [20:31] cjwatson, TREllis: cpp is already marked Multi-Arch: allowed; packages that need to be able to depend on a foreign-arch version of cpp need to be updated to depend on cpp:any [20:32] TREllis: because it's not correct to say that a cpp package of any architecture will satisfy the dependency on cpp for a package of any other architecture, because of the per-arch defaults cjwatson mentions. === TerminX_ is now known as TerminX [20:56] Ugh 20 hours for PPA builds [20:57] SpamapS: powerpc is worse :) [20:58] micahg: yeah, because in the end, you get a powerpc package. ;) [20:58] is listadmin broken for everyone else on precise? [20:59] The spam headers changed? [21:02] cyphermox: oh, it looks like siretart is about to upload a new libav-extra to Debian [21:03] micahg: ok [21:03] I'm fighting pino [21:03] oh, it's more than g_thread_init? (was the first failure I got) [21:07] is there a simple way to run sbuild and say "build this .dsc, with these extra .debs installed" ? [21:07] do I just have to build a new source chroot and stick them in there? [21:07] SpamapS: try --add-depends [21:08] micahg: how is that going to get my .debs into the chroot? [21:08] micahg: these are .debs that are not available yet [21:08] SpamapS: oh, I thought you meant dependencies :) [21:09] micahg: uploading right now [21:09] SpamapS: dpkg in --pre-build-commands from a bindmount dir in the chroot might work [21:09] siretart: thanks [21:09] micahg: yeah that seems doable but eeeeevil ;) === kirkland` is now known as kirkland [21:10] SpamapS: actually, you might need --chroot-setup-commands, not sure [21:11] SpamapS: I can tell you how to add a PPA to a single run :) [21:12] --add-depends (assuming I didn't miss somebody already saying that while I was disconnected) [21:12] micahg: I'm not getting a failure for g_thread_init at all, but getting all these vala errors (and now that I've fixed them I'm doing to one error in the generated C code [21:13] cyphermox: are you building 0.2.11+dfsg-1? [21:14] yes, just found out I didn't properly make sure I was building with valac-0.10, not valac-0.14 [21:15] micahg: dpkg -i seems to be working [21:15] micahg: or rather --chroot-setup-commands w/ the dpkg -i [21:15] cool, good to know :) [21:18] of course.. its complicated because I *also* need apt-get -yf install [21:18] but, seems to progress from there [21:19] SpamapS: just chain another --chroot-setup-commands afterwards [21:21] mciyeah it worked ok [21:22] tab complete fail [21:23] siretart: are you uploading to Ubuntu also or do you want me to? [21:24] micahg: I'm about to crash, if you want, feel free, otherwise I'll do it tomorrow [21:24] ok, I'll take care of it, thanks === salem_ is now known as _salem [21:25] micahg: in case you're doing it, I've pushed my branches to git.debian.org. IME, merging the git branches makes it pretty easy [21:25] siretart: it's just a sync, so I was going to grab from incoming [21:25] micahg: oh, right. that makes it indeed even easier. [21:26] good night! [21:26] good night siretart [21:35] tumbleweed: are you still having problems w/ the ubuntu menuproxy on precise? [21:44] who gets to send emails to ubuntu-devel without having to be moderated? [21:44] anyone in the whitelist [21:44] maybe that's tautologous :) [21:45] is that something that I should be on, or is it normal for most people to go through moderation? [21:45] I ust flushe dthe list from 145 moderated mails down to about 40. [21:45] the charter is "posting moderated for non-developers" [21:45] ok [21:45] https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-December/000227.html [21:45] so it's not that I've screwed up my subscription to it [21:45] in practice we generally add sensible people to the whitelist when we're bored of accepting their posts [21:46] (this is written up in https://wiki.ubuntu.com/UbuntuDevelModeration) [21:46] cool, thanks [21:46] me and mailing lists have a love/hate relationship, so I wasn't sure if I was doing something wrong [21:46] mhall119: your mail should now have gone through. [21:46] thanks Daviey [21:48] cjwatson: is there a sane way to sync from incoming? [21:48] slangasek: would you have any ideas or comment to add to https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/920609 ? [21:48] Ubuntu bug 920609 in ecryptfs-utils (Ubuntu) "likewise-open users with migrated home directory won’t decrypt automatically" [Low,Confirmed] [21:49] * micahg just realized there's no source.changes file to sign [21:52] jbicha: no, it looks like tha tissue is sorted now. The question is why we are loading menu-proxy at all when not in unity. And TBH, without big smoking bugs to point at, it doesn't concern me that much [21:53] micahg: syncpackage --no-lp, or wait [21:54] * micahg supposes he can wait 4 hours [21:54] cjwatson: when's the next CD run? [21:54] takes a bit longer than that before gina gets round to the import IME [21:54] depends on the CD [21:55] ubuntu studio (libav-extra is out of sync) [21:55] 17 18 * * * [21:55] (UTC) [21:55] ah, so it was already [21:55] so 20 and a bit hours [21:55] ok, I"ll just wait then === negronjl` is now known as negronjl === _salem is now known as salem_ [22:15] kirkland: do you know what the pam stack looks like in this case? [22:19] infinity: Any ideas on https://launchpad.net/ubuntu/+source/python-qt4/4.9-2ubuntu2/+build/3121207 - seems it's arm* specific. [22:28] ScottK, I remember a similar error from last year, I wonder if some patches got dropped [22:28] "unsupported function argument type - provide %MethodCode and a valid C++ signature" [22:28]