=== attente is now known as attente_zzz [00:30] SpamapS: hey - looking at http://upstart.ubuntu.com/cookbook/#kill-signal , i'm not sure i'm reading it right. [00:30] will it first send the signal specifid in 'kill signal', then wait 'kill timeout' seconds, then send sigterm? [00:31] or does it wait 'kill timeout' seconds after pre-stop, then send the 'kill signal' signal then consider itself done? [00:39] * hallyn out - bbl [00:40] is there someone available to review SRUs? [00:43] * RAOF is today's SRU victim. [00:43] RAOF: better than fixing nux bugs! :) [00:44] RAOF: i believe cyphermox uploaded network-manager-gnome into precise-proposed for me, was wondering how to get someone to review it. (lp: #780602) [00:44] Launchpad bug 780602 in network-manager-applet (Ubuntu Precise) "nm-applet leaks memory and stops functioning after a while" [High,In progress] https://launchpad.net/bugs/780602 [00:45] That seems pretty sub-optimal. [00:45] yup [00:45] RAOF: there are a bunch of other fixes that will need backporting to fully fix that one, nm-applet is just the first of several [00:46] I'm currently wading through the compiz/unity stack SRUs in precise. I may not get to nm today. In which case, feel free to ping tomorrow's SRU vanguard, SpamapS ( https://wiki.ubuntu.com/StableReleaseUpdates#Publishing ) [00:46] RAOF: ah, ok. makes sense, thanks [00:53] Hi, I am looking for a development job [00:53] in Canonical/Ubuntu === chilicuil_away is now known as chilicuil [01:26] Argh. I ended up as TIL for both emacs24 and xemacs21? This is some kind of penance, right? [01:32] "TIL" == "touched it last" ? [01:33] cjwatson: and for your next trick... [01:33] sarnold: yes [01:35] .. and thus The Expert? :) [01:36] The person who touched a package last is by default responsible for merging newer changes to it from Debian [01:36] i.e. you diverge, you get to eat the costs of divergence [01:36] strong penalty for oddball packages.. [01:37] It really is touched-it-last though, not anything more sophisticated, so if like me you do lots of rebuild-only uploads for library transitions, you tend to get bitten a bit :) [01:37] sarnold: Penalty for not putting the effort in to make them less oddball, yes :) [01:38] Plus, you know, if they're that odd then maybe they do actually need an expert to merge them [01:38] cjwatson: penalty for not teaching TIL to be smarter. [01:38] * sarnold fears for whoever touched hardy and lucid perl, those have been eating my brain for the last week now :/ [01:38] We don't do merges in stable releases [01:39] lifeless: Or that [01:39] cjwatson: maybe this is your incentive ;) [01:39] (I'm used to it, complaints are non-serious) [01:40] lifeless: I'm not sure it would save enough time over my working life :) [01:43] stgraber: ah, right [01:47] cjwatson: clearly you need to work longer hours for more years === fisted_ is now known as fisted === jasoncwarner_ is now known as jasoncwarner === fisted_ is now known as fisted [04:07] My new laptop's wireless card doesn't work in Ubuntu its a Realtek RT8723AE any suggestions? [04:08] Also I can't connect to the internet when wired neither. [05:40] ideas how to disable the braindead sbuild default to put the link to the build logs to $PWD? [05:40] didn't have it on 12.04 [05:41] My wireless and wired internet don't work in Ubuntu. My wireless card is a Realtek RT8723AE [05:41] any suggestions? === doko_ is now known as doko [05:48] tjaalton: I believe there's a build log location variable in ~/.sbuildrc [05:50] tjaalton: man sbuild.conf - LOG_DIR is what you're after. [05:50] RAOF: I had both set for 12.04, now it broke with 12.10 [05:51] Fair enough. I didn't set that last time I rebuilt, so I didn't notice. [05:51] also, the logs do go there, just that the symlink used to go to $build_dir [05:53] and $build_dir is "deprecated", but no idea what replaces it [05:53] guess it's just a bug then [05:54] Good morning [05:54] meh, the SRU queues are really long [05:54] * pitti rejects mvo's pygobject upload, I already uploaded that fix two weeks ago [06:01] slangasek, ev: I cannot participate in the sprint prep meeting at 1700 UTC; earlier works [06:01] or tomorrow [06:18] apw, infinity: bah, https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-proposed-adt-linux/3/ARCH=amd64,label=albali/ [06:18] apw, infinity: it's again that "apt-get source linux does not download linux" trap/bug/misfeature [06:19] since debhelper compat v9 uses multiarch path for libexecdir, it's ok to install support binaries under /? the debian policy is a bit vague about it, only talks about /usr/lib/ === chilicuil is now known as chilicuil_away [06:28] pitti: You want --only-source on that commandline. [06:29] infinity: ah, thanks; I was just committing -o APT::Get::Only-Source=yes [06:29] but that's easier [06:30] pitti: Apparently, appending exact versions also forces only-source mode. [06:30] pitti: And if you're autotesting based on specific versions, maybe you want that anyway? [06:30] we don't currently pass a version [06:30] (ie: apt-get source linux=3.7.0-4.12) [06:30] but yeah, this behaviour is irritating [06:31] You're not currently passing versions, but we probably want to if we're tying (some of) this into proposed migration. [06:31] Since we want to know we're testing the right thing. :P [06:31] Oh, though this is for rdep testing, I guess, which is different. [06:32] pitti: The behaviour is wildly unintuitive to developers who think in terms of source packages, but the inverse is true for people who want "apt-get source libc6" to work, so... [06:33] pitti: I think we just need to live with typing --only-source occasionally. :P [06:33] mappign binaries to source packages does not require to prefer the binary packages' source [06:33] yeah, but I need it so seldomly that I keep forgetting about it [06:34] pitti: It's unintiutively broken either way. Either it doesn't always get the binary's source, or it doesn't always fetch the source you thought it would. I'm not sure there's a right answer at this point. [06:34] (There may have been a right answer 10 years ago, but now the behaviour's a bit set in stone) [06:35] And I'd argue the right answer 10 years ago would have been to try source names first, then binary mapping, without a --map-binary option, but whatever. [06:35] pitti: hey, due to the default score of the ubuntu-unity ppa behind lower than distro, and the powerpc pb, even the build started 30 hours ago are still not in. So no automated upload :/ Can you please bump the score for today's upload so that it doesn't happen again? [06:35] only for now: [06:35] https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4017572 [06:35] https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4017828 [06:36] https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4018003 [06:36] https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4018013 [06:36] and that's it :) [06:36] didrocks: Is it world ending if it doesn't get in right away? [06:36] didrocks: done [06:36] yeah, with one buildd being out and the other building libo there's not much capacity left [06:36] * infinity isn't entirely sure why a daily build would need priority... [06:36] infinity: well, we start to have daily landing and trying to check everything does work indeed. It's been 2 days that my uploads are piling up [06:36] thanks pitti [06:36] 63 jobs (9 hours 40 minutes) [06:37] infinity: so I think at least, they should have the same score than distro has [06:37] Err, we plan to land unity in the distro daily? Really? [06:37] Maybe I should have attended this meeting. :P [06:37] infinity: from yesterday, it started with "start in 8 hours" and was never released [06:37] infinity: yeah [06:39] This seems like a strange step backward from when we were previously asking people to not do daily builds. [06:39] Now we've just decided that "oh, it's okay, cause we're doing daily build to push them to the archive"? [06:39] pitti: did you for overlay-scrollbar and notify-osd? I didn't see the bumping [06:39] didrocks: ah, sorry [06:39] infinity: no, there is an autopilot step before to validate [06:40] didrocks: That doesn't address the resource usage... [06:40] infinity: it does, this will remove the commit-build staging ppa [06:41] s/remove/replace/ [06:41] thanks pitti :) [06:41] A daily build is a daily build... [06:41] infinity: the other is per commit [06:41] not per day [06:41] didrocks: was that also a devirt PPA? i. e. with powerpc [06:41] so no a commit build != daily build [06:42] pitti: it was, but powerpc was blacklisted [06:42] didrocks: ah, I was wondering how you did not fall into the powerpc bottleneck with that [06:42] pitti: we did at start, but then, removed it :) [06:43] *sigh* [06:43] There are so many things about this I don't like. [06:43] Automated testing can't check the diff against the previous version before upload to see that it's sane. [06:43] infinity: the UDS session was a good start to attend [06:43] Nor can an automated uploader. [06:43] didrocks: I was double/triple booked all week. [06:43] didrocks: I *was*, however, at the buildd usage session, where this didn't come up. :P [06:44] Besides, "it passes the test suite" is not actually an indicator that it's ready for release. [06:44] * didrocks would like to avoid reiterate again all the discussion we had at UDS… [06:45] infinity: we have 400 tests per config [06:45] for autopilot, most of them being integration tests [06:45] And if someone's in the middle of landing a new feature that lacks test coverage? [06:45] infinity: first, this will be reverted [06:46] infinity: second, distro is looking at all merges [06:46] infinity: third, PS agreed that shouldn't happen and we have explicit rules/people to contact in PS if it happens [06:46] If there's human auditing, then why use automated uploading? [06:46] infinity: it's an audit, not doing the heavy lifting everyday [06:46] (There's still no auditing of the source package itself) [06:47] infinity: you should try to do unity at some point [06:47] But, ultimately, I can come up with reasons I think it's a lousy idea all day, and you'll just say "let's not discuss this again, even if it's your job to do so". [06:47] we'll see if you can audit the whole stack, 60+ packages alone :) [06:47] So, whatever. [06:47] Ultimately, I don't think we ship a single piece of software that actually needs to build/update every day. [06:47] and maybe you will have another view of "I have time to review every line changed in a new upstream version" [06:48] Auditing source uploads doesn't imply necessarily reading every single line. [06:48] infinity: I have nothing against discussion, but reiterating the whole process explanation every time someone not at the session is a little bit a waste of time [06:48] It does mean checking the diff against the previous version uploaded. [06:48] infinity: this is what we do pro-actively looking at upstream merge request [06:49] didrocks: Yes, discussion is a waste of time, I'm arguing that the current state of affairs is a misallocatoin of resources. So, a different waste of time. [06:49] didrocks: Reviewing merges is not reviewing the source that gets uploaded. [06:49] * infinity should go to bed instead. [06:49] infinity: it's juts about reviewing the changes in a more manageable manner [06:53] didrocks, pitti: definitely the buildd session was the place to mention this. it's no good to just use resources without announcing this ... [06:54] doko: it was announced before, the session was in conflict with other settle by fundations where I was required [06:54] doko: and again we trade a commit-build ppa for a daily-build one [06:54] so I see that more as a resource gain as hilighted in the session [06:54] that's your view [06:54] didrocks: Unless no one ever committed to unity before, it can't have actually been commit level. [06:55] didrocks: Cause it didn't trigger 30 builds per day or anything. [06:55] didrocks, I didn't see it in the whiteboard for the session either [06:56] infinity: https://launchpad.net/~unity-team/+archive/staging/+packages?field.name_filter=unity&field.status_filter=&field.series_filter=quantal [06:56] infinity: look at unity [06:57] unity - 6.12.0bzr2935pkg0quantal0 [06:57] rev 2935 [06:57] unity - 6.12.0bzr2934pkg0quantal0 [06:57] rev 2934 [06:57] unity - 6.12.0bzr2933pkg0quantal0 [06:57] rev 2933 [06:57] … [06:57] I put it in place, I know what is pushed to the ppa [06:58] Fair enough. [06:59] Of course, there are also large spans there between uploads sometimes. [07:00] well, it is what it is; it doesn't seem fruitful to argue about it now [07:00] infinity: yeah, most of PS is working on other things than unity these days, you can look back at quantal/precise release cycle and you will see a high commit activity (~15 per day for unity alone) [07:01] pitti: Hrm? Is this some sort of "nothing changes once a solution is implemented, nyah nyah"? :P [07:01] if ppc keeps being a bottleneck for this, the answer cannot be to ask developers to upload less really [07:01] pitti: If the kubuntu guys uploaded KDE daily snapshots every day, we'd just drop their entire packageset and tell them to find another distro. [07:02] pitti: I realise that PS/unity get to be unique snowflakes here, to a point, but I don't actually see the value in daily snapshot uploads. [07:02] infinity: that's not a canonical project; if they would pay for the extra resources.. [07:02] A real human can say "yeah, a bunch of stuff has been fixed and some new features have landed, let's upload" once or twice a week, at most, I'm sure. [07:02] pitti: Excellent. If Canonical would pay for resources for unity daily builds, I'd be fine with it. :) [07:02] * pitti didn't really intend to get pulled into this, and goes back to other stuff [07:03] infinity: (C does, and nobody else does..) [07:15] cjwatson: ok, all rdepends of pygobject check out now and are green; can you please remove the britney block? [07:15] cjwatson: thanks again for setting it, it was helpful; and also a nice trial run what would happen once that's automatic [07:16] pitti: I can kill the block. [07:16] infinity: ah, thank you [07:16] pitti: Done. [07:17] * pitti sticks fingers in ears and closes eyes while it lands [07:20] good morning [07:20] hey dholbach [07:20] hi pitti [07:22] hey dholbach [07:22] salut didrocks [07:25] do we have some more folks interested in signing up for https://wiki.ubuntu.com/UbuntuDeveloperWeek? [07:26] infinity: on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html, the bits without "Section:" are main, or is Section: only shown sometimes for other reasons? [07:27] pitti: No section would mean main, yeah. Not the most intuitive way to display it, I suppose. [07:27] good to know, thanks === Logan_ is now known as Guest76402 === Logan__ is now known as Logan_ === smb` is now known as smb [08:51] good morning === pitti is now known as universal_tb_pri === universal_tb_pri is now known as pitti === stan_ is now known as stan === yofel_ is now known as yofel === Tonio_ is now known as Tonio_aw === Sweetsha1k is now known as Sweetshark [09:47] bdrung: I agree with infinity -- no separate SRU for bug 585910. And for quantal 3.6.4rc2 has been tagged yesterday and was build locally containing the fix: https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/585910/comments/50 [09:47] Launchpad bug 585910 in libreoffice (Ubuntu Quantal) "[Upstream] Impress Font fuzzy in presentation mode when Use hardware acceleration enabled" [Undecided,Triaged] === mcclurmc_away is now known as mcclurmc [10:13] SpamapS: php5 got uploaded as 5.4.9-1 to experimental fixing the orig.tar [10:21] pitti: can you please reject https://code.launchpad.net/~vanvugt/ubuntu/quantal/compiz/upstream-expo-patch-quantal/+merge/136606? (the change is not SRUable) [10:22] didrocks: done [10:22] thanks :) [10:36] Sweetshark: why an rc version? [10:55] bdrung: rc2 will most likely be final. hasnt declared as such though. [11:09] cjohnston: hi [11:09] cjohnston: sorry, wrong tab complete [11:09] cjwatson: hi [11:10] cjwatson: I'm interested in netbooting a uefi machine for hardware certification [11:11] cjwatson: I have some interesting material on the wiki (https://wiki.ubuntu.com/UEFI/PXE-netboot-install) [11:11] cjwatson: I wanted to ask if there is anything new in that area that is not on the wiki there and what is the secure boot story [11:13] tjaalton: It's a bug, and fixed in sbuild 0.63.2-1 [11:14] zyga: UEFI netbooting is known-broken right now due to a GRUB tftp handling bug, which slangasek has promised to distil down to a test case that I can debug [11:14] cjwatson: ah, thanks [11:14] zyga: in principle it ought to work with SB once that's fixed [11:14] cjwatson: ok, so I'll resort to non-secure path for now [11:15] zyga: provided that you do *not* generate your own GRUB image, but use the signed one [11:15] cjwatson: I don't own any uefi hardawre, can I perform experiments on this with any simulation or virtualization tools to get a feel of it? [11:15] (i.e. the procedure in the wiki page will never work with SB) [11:15] zyga: google OVMF [11:15] ok [11:15] thanks a lot :) [11:15] yay [11:15] zyga: you can build it with -D SECURE_BOOT_ENABLE (or possibly -D SECURE_BOOT_ENABLE=1, I forget) to add key handling support [11:15] you just saved me a lot of time reading the web :) [11:17] zyga: there's a PDF on the signing bits linked off http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF [11:17] cjwatson: my goal is not to dive too deep into the secure parts, just to see how uefi affects certification labs and our netbooting process [11:18] cjwatson: I'm actually tying to see if we can still pass a kernel command line the same way we did before [11:18] cjwatson: but since I'm not strong or either uefi or netboot in general I need to get some experience with just playing around with this [11:20] I don't know how you pass the command line right now === _salem is now known as salem_ === chilicuil is now known as chilicuil_away [12:15] hi! does something in Ubuntu change the GIO/GVfs settings for applications which are running as root? [12:16] my program needs to run as root and downloads some files via HTTP, but only the "file" GIO module is loaded [12:16] when running not as root, GVfs supports all mimes [12:17] mdeslaur: Would you care to merge sbuild from unstable? You're TIL, and it has a useful bug-fix to the log file location. [12:18] cjwatson: sure, I'll try and do it today [12:19] cjwatson: I'm not entirely sure, that part of certification is incredibly dusty, we seem to use debian-installer and casper [12:19] cjwatson: I'm experimenting with qemu and tiano core so that part is good [12:19] zyga: I believe you pass a command line to d-i/casper in some way [12:19] possibly pxelinux append or something? [12:19] mdeslaur: thanks [12:24] cjwatson: yes, I'm just unfamiliar with all the tools so my answers are not precise === amitk is now known as amitk-afk === cpg is now known as cpg|away === attente_zzz is now known as attente === Tonio_aw is now known as Tonio_ [13:28] i just reported a bug in network manager, bug 1084064. is this the right channel to indicate? [13:28] Launchpad bug 1084064 in network-manager (Ubuntu) "Can not ssh to raring VM's using hostname" [High,Confirmed] https://launchpad.net/bugs/1084064 [13:32] psivaa: the people that need to know get notifications or mails automatically. [13:34] OdyX: this bug is blocking the desktop testing, so it's kind of urgent [13:34] s/the/our [13:37] cyphermox: ^- [13:38] cjwatson: thanks [14:10] mdeslaur: that cups security bug is so depressing . [14:10] OdyX: yes, it's never ending :( [14:10] OdyX: ConfigFilePerm is pretty neat :) [14:11] mdeslaur: I pointed out DocumentRoot too. Just set it to /etc/ or even / and you can read the whole system. :( [14:11] mdeslaur: did you see the changes I pushed to git's master branch ? [14:11] OdyX: no, one sec, I'll take a look [14:11] http://anonscm.debian.org/gitweb/?p=pkg-cups/cups.git;a=shortlog;h=refs/heads/master <- mdeslaur [14:16] hallyn, hey, seems like your ppa qemu-linaro upload failed but not due to the spice on 32b change? [14:16] OdyX: this is going to be complicated for stable releases [14:17] mdeslaur: yes. But as cupsd.conf is modified by users through a web interface, I don't really see another way forward that keeps their modification. Moving configuration stanzas around in the postinst before server restart would work but would be a hell to manage. [14:18] mdeslaur: with my preinst, someone with clean pre-files-split would not get a prompt on upgrade. [14:19] mdeslaur: moving to ucf has the advantage of easing such changes in the future afaIui [14:19] seb128: yup, i can't quite figure out what's wrong [14:19] do packages using python in raring now need to add python-minimal to build-deps or something? [14:19] Generally python rather than python-minimal, but yes [14:20] OdyX: are you planning on simply dropping the config items that moved to the new config file? I wouldn't think they would be used very much on debian/ubuntu anyway... [14:20] hallyn, btw is it ok if I backport http://libvirt.org/git/?p=libvirt.git;a=patch;h=efe6c8021146d046846ead5b5efc9828d97c1ceb ? [14:21] hallyn, that should fix "virsh -c qemu:///session" (or gnome-boxes) being broken in quantal [14:21] cjwatson: i see. it was pulled out of essential? [14:21] hallyn, that issue is fixed in 1.0 already in raring [14:21] hallyn: Yes [14:21] mdeslaur: the preinst only drops it if it is unmodified [14:21] hallyn: Ultimately we don't want to have Python 2 on images, and this was incompatible with python-minimal being Essential [14:21] seb128: no objection from me on that, thanks [14:21] seb128: is that for raring only? [14:22] Plus we hardly ever truly relied on it being Essential anyway, due to the structure of Python policy [14:22] OdyX: right, but you aren't planning on attempting to move them yourself to the new file, are you? [14:22] hallyn, no, quantal only, raring has it fixed (the patch is in libvirt 1.0) [14:22] cjwatson: ok, thanks. i didn't want to blindly add that without making sure i wasn't papering over something [14:22] seb128: cool. ok. lemme try another ppa build and then push qemu-linaro hopefully to r [14:23] hallyn, excellent, I start a local build but it's running for over an hour, I start regretting it :p [14:23] start->started [14:23] mdeslaur: I'm thinking about fiddling with cups-files.conf in postinst to move stanzas from cupsd.conf to cups-files.conf . [14:23] hallyn, I might just wait on your new ppa upload ;-) [14:23] seb128: so this gnome-boxes thing is pretty cool? [14:24] mdeslaur: the thing is that's probably not acceptable for Debian stable. disabling the whole webinterface is probably the only thing we would do. [14:24] hallyn, I don't know but it looks nice, that's why I want to try it [14:24] mdeslaur: that, or as pitti says, change uid to access files, for logfiles and webinterface. [14:24] hallyn, it's the GNOME ui to deal with vms [14:24] hallyn, http://blogs.gnome.org/mclasen/2012/09/07/a-look-at-gnome-boxes/ [14:24] OdyX: it's more complicated than that...the cupsd daemon accept PUT requests for config files from the command line [14:24] hallyn: It's actually non-Essential in quantal, but it took us a while to remember to pull it out of buildd chroots [14:25] OdyX: the web interface is just a little part of the ways to modify cupsd.conf [14:25] mdeslaur: ah yeah, shit. === amitk-afk is now known as amitk [15:09] cjwatson: i notice you just uploaded a new libcap2. looking at bug 1084000, is the answer there to just copy in the capabilities.h from the kernel, or can we add linux-libc-dev to build-deps and not have libcap2 use its own file? [15:09] Launchpad bug 1084000 in libcap2 (Ubuntu) "libcap2: List of capabilities not in sync with the linux kernel" [Undecided,Confirmed] https://launchpad.net/bugs/1084000 [15:10] hallyn: Don't know anything about it, I'm afraid - I was just doing a monkey-see-monkey-do merge [15:10] linux-libc-dev is build-essential [15:10] adding it to build-deps will be a no-op ... [15:11] linux-libc-dev doesn't seem to have a capabilities.h, so perhaps you should indeed update libcap2's copy [15:12] cjwatson: apt-cache tells me Priority: optional [15:13] am i looking at the wrong thing? [15:13] hallyn: "Build-Essential: yes" [15:14] dpkg -S tells me /usr/include/linux/capabilities.h came from linux-libc-dev though [15:14] hallyn: But, more to the point, you can't compile even a trivial hello.c without linux-libc-dev [15:14] Since libc6-dev depends on it [15:14] ok [15:15] my feeling was that copying in a new file just begs getting out ofsy nc again. seems like it should come straight from kernel source. but if that's the way, i'll copy in the new file... [15:15] cjwatson: thanks [15:15] wait a sec [15:15] do you mean linux/capability.h? [15:16] yes, looks like you do [15:17] ok, so one reasonable approach might be to convince libcap2 to stop using its internal copies of the relevant headers in favour of the system ones [15:17] if you do that, you should confirm a couple of things: [15:17] * that it doesn't have any local patches applied to those headers [15:18] * that using the headers associated with a newer kernel doesn't e.g. cause the corresponding binaries to explode when run on top of an older kernel (such as is in use on the buildds) [15:18] you'll have to modify its build system though - it's not a matter of adding a build-dep [15:19] i'll write the upstream author. [15:19] sometimes the path of least resistance is just to update the local copy, since it's not like kernel APIs are supposed to change *that* often [15:19] i'd rather get the new version upstream first and take it from there than to reproduce myself [15:19] and from an upstream point of view, not all distros package them properly for userspace use [15:19] * cjwatson nods [15:20] thanks, ttyl [15:31] pitti: figured you probably wouldn't make that meeting, don't worry about it; it's mostly for giving the other two their marching orders ;) [15:32] slangasek: ack :) [15:42] jodh, barry: http://paste.ubuntu.com/1394693/ <- am I missing something? output appears identical under python2.7 and python3.3 with that change [15:43] stgraber: http://docs.python.org/3/library/subprocess.html#frequently-used-arguments [15:44] barry, thanks for sponsoring :) [15:44] stgraber: 2to3 expects further changes - like removing has_key() and 'b' prefix for re.match strings. [15:44] mitya57: np. just doing last few local tests before uploading [15:45] re.match doesn't have to take a byte string as the pattern - it should only do that if the string you're matching is also bytes [15:45] ok. by the way, do you know if "make unittests" is supposed to do anything? it doesn't work for me... [15:46] right, so in this case universal_newlines=True would mean that re.match would be operating on Unicode and you *don't* want a b prefix [15:46] barry: yeah, was wondering if it really was that simple to port to python3 as the missing universal_newlines and the string.split were the only obvious issues. I still plan to do a PEP-8 pass afterwards and then look at whatever 2to3 complains about. But based on what I heard on mumble, I expect it to be significantly trickier [15:47] stgraber: if you want to take point on that issue, that's cool with me (though please assign it to yourself). i'm happy to review, test, consult [15:49] slangasek, are you aware of any rotation support in plymouth (despite doing a rotated theme) ? it always comes up in portrait on the nexus7 here [15:49] seb128: do you suppose somebody desktopy might be able to take over the libgksu merge from me? I'm TIL due to a no-change rebuild upload I did, but it has a huge pile of patches [15:49] (the tty is rotated on kernel level at initialization time) [15:49] and I'm not too sure I can merge it competently [15:49] cjwatson, I can do it yes [15:49] lovely, thanks [15:50] seb128: fwiw I'm rejecting your appmenu-gtk precise SRU for bug #1077095 because it crossed mid-flight with a series of SRUs for bug #932860; can you rebase and re-upload? [15:50] Launchpad bug 1077095 in appmenu-gtk (Ubuntu Quantal) "Please blacklist "IBM Notes"" [Low,In progress] https://launchpad.net/bugs/1077095 [15:50] Launchpad bug 932860 in appmenu-gtk (Ubuntu Quantal) "Broken (or missing) multiarch support" [High,In progress] https://launchpad.net/bugs/932860 [15:50] if you have any foundationsy merges you want to inflict on me, I'm happy to swap :) [15:51] barry: ok, will do. Should be pretty easy as I've been doing a fair bit of that lately :) [15:51] ogra_: plymouth didn't do any rotation last I looked, no [15:51] hmm, k [15:51] stgraber: awesome! feel free to take on xapian next [15:51] i wonder why it doesnt pick it up from the console though [15:52] barry: hehe, you can keep that one, I don't want to steal all your work ;) [15:52] * barry mumbles curses under his breath [15:52] barry: oops [15:52] missing b-d I guess [15:52] mitya57: uh oh [15:53] mitya57: what? [15:53] cjwatson, yw [15:53] slangasek, ok, will do, thanks [15:53] barry: https://launchpadlibrarian.net/124325279/buildlog_ubuntu-raring-amd64.python-defaults_2.7.3-3ubuntu1_FAILEDTOBUILD.txt.gz [15:53] oh, blast, I think I need an ubuntu-meta upload to get a signed kernel onto 12.04 images [15:54] mitya57: how odd. i wonder if my source chroot already has that installed or something [15:54] I'm sure it was building in chroot when I tried it, but it was a month ago or so [15:54] cjwatson, thanks for the offer but I don't see anything foundationish on my TIL list atm so I think I'm good ;-) [15:54] mitya57: i *just* built it in an updated raring chroot, successfully [15:56] mitya57: huh. yeah, my sbuild definitely found rst2man :/ [15:56] hello [15:56] is someone here responsible for "Privacy" settings ? [15:57] barry: python-docutils *is* in build-depends [15:57] but it does some postinst trick to add /usr/bin/rst2* links, maybe that didn't work? [15:58] barry: it built on i386, so presumably you need to do a -B build [15:58] mitya57: look higher up: [15:58] /bin/bash: lsb_release: command not found [15:58] what is -B? [15:59] ah, dpkg-buildpackage -B? [16:00] which i think is the default for sbuild [16:02] Normally, yes; -A/--arch-all and --no-arch-all change this === Tonio_ is now known as Tonio_aw [16:03] barry: so I don't need to do anything, right? [16:04] mitya57: not yet ;) [16:04] * barry reproduces the failure with --no-arch-all [16:05] mitya57: i'll come back to this after the meeting, though if you want to keep working on it in the meantime, i won't complain :) [16:05] you might have $build_arch_all = 1; in .sbuildrc or something [16:06] barry: the only thing I can do is a new changelog entry, what else? [16:06] cjwatson: indeed, i do [16:07] * mitya57 prefers pbuilder, it built here without any configuration change === fisted_ is now known as fisted [16:21] cjwatson: `sbuild --arch-all tox_1.4.2-1.dsc` succeeds in a raring chroot. then there's this: https://launchpad.net/ubuntu/raring/+source/python-tox/+builds?build_state=all [16:22] I'm not going to debug LP at the same time :) [16:22] Trying here - it may well depend on your chroot [16:22] :) [16:23] oh, "python-tox" is not a source package [16:23] s/python-tox/tox/ there [16:23] d'oh [16:24] ew [16:24] oh my, I just noticed why it works for you [16:24] there is some insanity here that downloads dependencies from the network if they aren't already installed [16:24] dholbach, did you notice that external links work now? now it's your turn to enable es translation :) [16:25] firewall off pypi.python.org or some such and you should see the same thing [16:25] cjwatson: yep. that's icky [16:25] mitya57, we might have to backport sphinx in our ppa [16:25] i'm sure there's some magical setup to prevent sbuild chroots from doing that [16:25] something involving lxc [16:25] dholbach: should I do it (thanks for sponsoring btw)? [16:26] cjwatson: yeah. it's bitten me before. oh well. better to fix that in debian first [16:26] mitya57, sure, if you want, that'd be awesome [16:27] ok, so I'll now upload it to my test ppa and then copy if it builds [16:27] mitya57, I won't get around to enable 'es' today [16:27] but it'll be great to do it! [16:27] do you mean I should do that? [16:27] barry: indeed, it's technically an RC bug in Debian too [16:27] even if nobody's noticed yet :) [16:27] won't it blow up when we enable it? [16:28] cjwatson: ;) [16:29] mitya57, I can enable it tomorrow if you prefer [16:29] mitya57, and also make sure we get it on developer.u.c properly [16:29] ok, that would be better [16:33] OdyX: thanks for the heads up, I'll do that merge today :) [16:33] OdyX: (re php) [16:46] hallyn, that ppa upload of your is buggy [16:47] hallyn, you updated the control it seems but rules still has [16:47]