[01:34] <jose> marcoceppi_: ping
[01:50] <marcoceppi_> jose: pong
[01:50] <jose> marcoceppi_: mind a quick PM?
[01:51] <marcoceppi_> sure
[06:34] <dholbach> good morning
[06:35] <jose> hello, dholbach! how's it been?
[06:47] <dholbach> hey jose
[06:47] <dholbach> good good - how about you?
[06:47] <jose> I'm fine :)
[16:22] <dholbach> all right my friends - I call it a day - see you all tomorrow!
[16:27] <jono> jose, hey
[16:28] <jose> hey jono
[16:28] <jono> apologies, but need to cancel the Q+A
[16:28] <jono> I am sick
[16:28] <jono> my son infected us all
[16:28] <jose> ok
[16:28] <jose> take care!
[16:28] <jono> sorry about this jose
[16:28]  * jono slopes off to bed
[23:31] <jose> oh, cool! gandi.net has these 'gandi supports ubuntu' tshirts and if you buy one 100% goes donated to Ubuntu!
[23:31] <jose> (100% of the profit)


[08:39] <nteodosio> We need bug 2029473 released to release update-manager with Ubuntu Pro. What is preventing Fix committed -> Fix released?
[08:39] -ubottu:#ubuntu-devel- Bug 2029473 in software-properties (Ubuntu Xenial) "Backport Ubuntu Pro to Xenial" [High, Fix Committed] https://launchpad.net/bugs/2029473
[08:47] <seb128> nteodosio, I expect they probably don't do regular review of the queues for series out of standard support...
[08:47] <seb128> rbasak, ^ could you perhaps review that during your shift today? and is my assumption right/if so is that a better way for us to flag those uploads or should we just try to ping SRU vanguards?
[09:43] <rbasak> nteodosio: I'll try and have a look on my shift today.
[11:10] <ginggs> @pilot in
[12:03] <rbasak> seb128, nteodosio: the software-properties upload to Xenial links bug 2029089 instead of bug 2029473 I think?
[12:03] -ubottu:#ubuntu-devel- Bug 2029089 in distro-info (Ubuntu) "[SRU] Please backport UbuntuDistroInfo().get_all(result='object') to Xenial" [Undecided, Triaged] https://launchpad.net/bugs/2029089
[12:03] -ubottu:#ubuntu-devel- Bug 2029473 in software-properties (Ubuntu Xenial) "Backport Ubuntu Pro to Xenial" [High, Fix Committed] https://launchpad.net/bugs/2029473
[12:05] <rbasak> I also found bug 2003527 which I think is the same thing but in the newer series, as I was surprised that if we're additionally adding Xenial then the old bug isn't being used.
[12:05] -ubottu:#ubuntu-devel- Bug 2003527 in software-properties (Ubuntu) "Replace the Livepatch tab by an Ubuntu Pro one" [High, Fix Released] https://launchpad.net/bugs/2003527
[12:05] <rbasak> How do you want to organise the various bugs here?
[12:08] <nteodosio> rbasak, true it should be linking 2029473.
[12:09] <seb128> rbasak, nteodosio, let me fix that and reupload
[12:10] <rbasak> Thanks.
[12:11] <nteodosio> Bug 2029089 is no longer a requirement since bug 1978940 was fixed. Sorry, the situation is definitely messy because of the various components involved.
[12:11] -ubottu:#ubuntu-devel- Bug 2029089 in distro-info (Ubuntu) "[SRU] Please backport UbuntuDistroInfo().get_all(result='object') to Xenial" [Undecided, Triaged] https://launchpad.net/bugs/2029089
[12:11] -ubottu:#ubuntu-devel- Bug 1978940 in ubuntu-advantage-tools (Ubuntu Xenial) "u-a-t fails when distro-info is installed from backports on Xenial" [Medium, Triaged] https://launchpad.net/bugs/1978940
[12:12] <rbasak> Ah
[12:13] <rbasak> Well maybe it's easiest to pretend it still is? Because it's in proposed already and has been there for a while, and you have a versioned depends on it now.
[12:14] <rbasak> But I don't understand how bug 1978940 stops it being an issue. What if a user doesn't have backports enabled?
[12:15] -ubottu:#ubuntu-devel- Bug 1978940 in ubuntu-advantage-tools (Ubuntu Xenial) "u-a-t fails when distro-info is installed from backports on Xenial" [Medium, Triaged] https://launchpad.net/bugs/1978940
[12:16] <nteodosio> rbasak, backports are not enabled by default?
[12:16] <nteodosio> If not then yes we'd better depend on the former one.
[12:17] <rbasak> backports are not enabled by default> users won't receive backports by default. They are opt-in.
[12:17] <rbasak> OK, so we can leave everything as-is, release them together, and we should be OK I think.
[12:18] <rbasak> As long as the Depends line won't force a downgrade if the user has the backports version installed. I'll check that.
[12:18] <nteodosio> A downgrade of distro-info? Could it do that even though the backports version is higher than the proposed?
[12:19] <rbasak> If it's higher than the proposed version then that's fine - that's what I hadn't checked.
[12:19] <nteodosio> Ah alright. And thank you for having a look.
[15:03] <ginggs> @pilot out
[15:09] <jbicha> @pilot in
[15:28] <rbasak> mfo: could you take a look at bug 2038648 please - not necessarily you, but do you know who is looking after sosreport nowadays who might be able to take a look?
[15:28] -ubottu:#ubuntu-devel- Bug 2038648 in sosreport (Ubuntu Bionic) "package sosreport 4.4-1ubuntu<IP_ADDRESS> failed to install/upgrade: installed sosreport package post-installation script subprocess returned error exit status 1" [Undecided, Triaged] https://launchpad.net/bugs/2038648
[15:34] <mfo> rbasak, sure! i'll ping nikhil about it; he's subscribed to all bugs in sosreport, so may already be aware, but just in case.
[15:34] <rbasak> Thanks!
[15:34] <mfo> rbasak, You're welcome
[16:23] <nkshirsa> hi mfo rbasak o/ looking at 2038648
[20:12] <adrien> using git-ubuntu's .experimental-emptydirfixup, I can't tell it it actually does something: I ran it once and it changed the commit hash but when I run it again, it mentions reinstating the same directory, yet gives the same hash, and dpkg-buildpackage is still unhappy
[20:37] <rbasak> adrien: "git ls-tree -rt commitish|grep 4b825dc642cb6eb9a060e54bf8d69288fbee4904" should list all empty directories in a given commit.
[20:37] <rbasak> Does that help?
[20:38] <rbasak> If you're hitting the empty directory issue, then eg. pkg/ubuntu/devel should have some listed, commits you add won't initially, and correct use of emptydirfixup should restore them.
[20:53] <adrien> I can see the directory; dpkg-buildpackage -S says "dpkg-source: warning: ignoring deletion of directory wycheproof", is that actually normal?
[21:01] <adrien> and I have a bunch of modified files and I don't understand why (I know they're related to patches but the git tree is clean and I have no .pc directory), so I'll head to my bed now
[21:15] <rbasak> That sounds unrelated to git-ubuntu/git's empty directory issue


[00:10] <achiang> kirkland: you around?
[00:17] <kirkland> achiang: howdy man
[00:17] <kirkland> achiang: wassup?
[00:17] <kirkland> achiang: wanna meet me in Aspen in a couple of weeks?  :-P
[00:17] <kirkland> achiang: i have a saturday/sunday on the slopes coming up in a few weeks :-)
[00:22] <achiang> kirkland: ooh
[00:22] <achiang> kirkland: what weekend? i'm actually skiing silverton over president's day
[00:26] <achiang> kirkland: i have a relatively fresh maverick install, just installed virt-manager, and trying to create a VM, running into: http://pastebin.ubuntu.com/556023/
[00:28] <kirkland> achiang: hmm, interesting
[00:28] <kirkland> achiang: what does 'id' say about your user
[00:29] <kirkland> achiang: i'm interested in what groups its a member of
[00:29] <kirkland> achiang: specifically, you should be in the kvm and libvirtd groups
[00:29] <kirkland> achiang: the packaging should have added that for you
[00:29] <achiang> kirkland: i'm in libvirtd, but not kvm
[00:29] <kirkland> achiang: but if not, sudo usermod -a -G kvm $USER
[00:29] <kirkland> achiang: but if not, sudo usermod -a -G libvirtd $USER
[00:30] <kirkland> achiang: then you'll need to logout of all sessions and log back in (or just reboot)
[00:30] <kirkland> achiang: that's the most common mistake i've seen
[00:30] <achiang> ok, back in a jiffy
[00:30] <achiang> kirkland: but the packaging didn't add it
[00:30] <achiang> kirkland: should be easily recreatable
[00:30] <achiang> back in a sec
[00:30] <kirkland> achiang: right, well, the packaging adds libvirtd, maybe/maybenot kvm
[00:30] <kirkland> achiang: k
[00:30] <soren> You don't need to be in the kvm group.
[00:31] <kirkland> achiang: right, as soren is about to tell you, the kvm thing is now handled automagically by PolicyKit
[00:31] <soren> Um. No :)
[00:31] <soren> If you use the systemwide libvirt daemon (which you do if you're a member of libvirtd), you don't need to be a member of kvm.
[00:32] <soren> Besides, I think the time is ripe for chmod 666 /dev/kvm. It doesn't give you any privileges anymore that are worth containing.
[00:32] <achiang> back
[00:32] <achiang> trying again
[00:33] <achiang> and just read scrollback. :)
[00:34] <achiang> kirkland: soren: hm, adding myself to kvm group and restarting seemed to help on one machine
[00:34] <kirkland> achiang: rock
[00:34] <achiang> on another machine, i went into advanced options, deleted the console device, and it too could start
[00:34] <achiang> (without being in kvm)
[00:35] <achiang> so... is this a bug i should file?
[00:35] <kirkland> achiang: okay, glad to hear you're sorted out
[00:35] <kirkland> achiang: i'm not sure I understand the situation clearly enough to say so
[00:35] <kirkland> achiang: to be on the safe side, i'd say "yes"
[00:35] <achiang> kirkland: ok. i'll try and see if i can reproduce it
[00:35] <kirkland> achiang: mdeslaur maintains virt-manager for the most part
[00:35] <kirkland> achiang: cool, thanks.
[00:36] <soren> achiang: You basically need to be a member of either libvirtd or kvm. libvirtd is cooler, because it lets you fiddle with networking.
[00:36] <soren> ...but to just run virtual machines, either works.
[00:36] <achiang> kirkland: ok, i'll just file it against virt-manager, but won't assign it to anyone
[00:36] <kirkland> achiang: as for skiing, i'm out there the weekend of Feb 5/6
[00:36] <achiang> kirkland: another weird thing, i thought i had qemu-kvm installed, but when trying to create a machine, it says kvm is not installed
[00:37] <kirkland> achiang: ah, well, then, that'll make it hard to run vm's :-)
[00:37] <achiang> http://pastebin.ubuntu.com/556025/
[00:58] <ebroder> soren: uh, doesn't /dev/kvm basically get you the ability to muck with the whole kvm subsystem, or did that change? i don't like the idea of giving random users access to that without the admin opting in
[00:58] <ebroder> just like i don't want /dev/fuse to be 666
[01:07] <ebroder> err...wait...when did /dev/fuse become 666?
[01:08] <psusi> so what's a guy gotta do to get the whole natty archive rebuilt? ;)
[01:09] <ebroder> (or is it safe for /dev/fuse to be 666 because fusermount has finer controls?)
[01:09] <psusi> now that this gcc bug has been fixed...
[08:07] <dholbach> good morning
[08:12] <didrocks> good morning
[08:13] <Tm_T> K'day
[08:15] <soren> ebroder: What's so interesting about the kvm subsystem that you want to limit access to it?
[08:15] <davmor2> morning dholbach
[08:16] <dholbach> hey davmor2
[08:16] <soren> ebroder: I can't consume any more resources through it than you could otherwise do just with malloc or a tight loop. It's not like there's a limited supply of /dev/kvm or anything. Nor can you screw up other people's VM's. There's really no reason to limit access to it.
[08:17] <soren> ebroder: Once upon a time, having access to /dev/kvm meant you could lock memory pages in RAM. So a malicious user could create a VM with as much memory as the host, and you were DOS'ed.
[08:18] <soren> ebroder: Nowadays, KVM memory can be paged out, so it's no different from just malloc(<size of host ram>).
[08:23] <ebroder> soren: i'm more concerned about security issues. i basically trust unix file permissions. not sure whether i want to trust kvm any more than i have to
[08:24] <soren> ebroder: I'm not sure what you mean?
[08:24] <ebroder> in a nutshell, principle of least privilege
[08:24] <soren> ebroder: The memory of a virtual machine is as easy or difficult to get to as the memory of any other process.
[08:25] <ebroder> you're missing my point. i'm not concerned about the security of the guests. i'm concerned about the security of the host
[08:27] <soren> so am I. And I don't believe /dev/kvm exposes anything that compromises the host's security.
[08:27] <ebroder> you're assuming kvm is bug-free
[08:28] <soren> Not really.
[08:28] <soren> ..but the other 99.99% of the kernel isn't either.
[08:28] <soren> Yet we don't limit people's access to open sockets, for instance.
[08:28] <ebroder> sure, but it's all about minimizing the attack surface
[08:28] <soren> We could.
[08:28] <soren> but we don't. Because it's silly.
[08:29] <ebroder> and we are starting to patch out autoloading of obscure protocols and stuff
[08:29] <soren> a) kvm is not obscure
[08:29] <soren> b) there are bugs in non-obscure parts of the kernel, too
[08:30] <soren> I just don't subscribe to the idea of amputating my system to the point of uselessness in the name of security.
[08:31] <soren> I think this is a symptom of "oh, wow, there's a device node for this stuff! Let's limit access to it!"
[08:32] <ebroder> uselessness? it's not useless to reduce my attack surface by a whole subsystem when i personally run all of my vms managed by the system libvirtd
[08:33] <soren> I understand that we've worked around these limitations for kvm. I know. I did it.
[08:33] <ebroder> limitation? i'm not doing that because i think i have to
[08:34] <soren> Well, whatever you want to call it.
[08:34] <soren> We've worked around the fact that access to /dev/kvm has historically been restricted.
[08:35] <soren> If kvm had been implemented by way of a syscall interface, noone would have thought of trying to impose artificial limitations on access to it.
[08:35] <soren> (syscalls other than ioctl, that is)
[08:36] <soren> Anyway, this is going nowhere.
[08:36] <soren> and fast.
[08:39] <dholbach> query Sarvatt
[08:47] <doko_> siretart: please could you have a look at the xine-lib build failure? http://launchpadlibrarian.net/61920076/buildlog_ubuntu-natty-i386.xine-lib_1.1.19-2ubuntu2_FAILEDTOBUILD.txt.gz
[08:59] <wolfpack> I am getting error while trying to "branch" in bazzar .Error is "bzr: ERROR: exceptions.NotImplemented Error: should resend request to http://feeds.edge.launchpad.net/bazaar/, but this isn't implemented ".Can anyone provide help on this??
[09:00] <pitti> Good morning
[09:01] <didrocks> hey pitti
[09:04] <pitti> bonjour didrocks, comment vas-tu?
[09:07] <didrocks> pitti: ça va bien, merci, et toi? :)
[09:07] <pitti> tres bien, merci!
[09:12] <JoshTriplett> I just ran into something rather odd.  By way of Mozilla's "Game On" gallery page, I found a game which seems to copy a pile of content from the Ubuntu homepage and dummy it out, either due to copying parts of Ubuntu's page as a template or perhaps trying to get Google juice for random search terms.  Who might I go about reporting that to?
[09:14] <JoshTriplett> Specifically: https://gaming.mozillalabs.com/games/ led to https://gaming.mozillalabs.com/games/118/the-humanity-project which points at http://farsides.com/ ; check out the links in the green box at the bottom.
[09:20] <geser> JoshTriplett: contact<EMAIL_ADDRESS>(if nobody else gives you a better advice)
[09:21] <JoshTriplett> geser: Fair enough.
[09:21] <JoshTriplett> geser: Thanks.
[09:24] <JoshTriplett> geser: Mailed.
[10:02] <dpm> hi chrisccoulson, thanks for merging danilo's po2xpi branch. Do you think you could now look at automatically uploading the xpi's with every package upload, as we discussed? The easiest way I can think of is simply fetching them from http://releases.mozilla.org/pub/mozilla.org/firefox/releases/4.0b9/linux-i686/xpi/, and I guess it shouldn't be too different to what you are already doing for getting the translations for the Thunderbird locale packages
[10:05] <persia> Could that be semi-automatic, rather than automatic?  It seems like it could go very wrong or be very awkward in the case of a tiny SRU patch, or similar.
[10:21] <nobuto> !regression-alert
[10:21] <nobuto> ubuntu-docs 10.10.4 which was SRUed as Bug #677998 also contains unrelated changes, http://launchpadlibrarian.net/60441147/ubuntu-docs_10.10.3_10.10.4.diff.gz
[10:21] <nobuto> This causes regression Bug #690248 which shows using 11.04 in spite of using 10.10
[11:01] <Riddell> didrocks: we're blocking on bug 702026
[11:03] <didrocks> Riddell: I'll process it before EOD
[11:08] <ogra> seb128, poke ... where is that rhythmbox upload you talked about ? do i need to unseed it to get images ?
[11:09] <seb128> ogra, it's coming today, I ran into other issues yesterday and didn't get it done
[11:09] <pitti> ugh, seems that today's CDs grew by 70 MB, due to LibO?
[11:10] <ogra> seb128, k
[11:10] <ogra> pitti, switch to arm :) we still have space
[11:11] <pitti> the language pack rebuild saved 50 MB
[11:11] <pitti> and LibO added 130
[11:11] <pitti> ah, it now pulls in Java
[11:11] <pitti> openoffice.org-common (17.0 MB)
[11:12] <pitti> libreoffice-common (36.6 MB)
[11:14] <pitti> ah, the langpack rebuild saved 8.5, sorry
[11:22] <debfx> Riddell: could you please reject mumble from lucid and maverick-proposed, it will be handled by a security upload
[11:24]  * ogra sighs about 160 bugs in his bugmail
[11:24] <ogra> bah
[11:24] <ogra> and most of them seem to be expired installer bugs ... i wonder if thats ok
[11:26] <Riddell> debfx: ok
[11:27] <pitti> ogra: those are the best kind, no action necessary :)
[11:27] <ogra> pitti, i really doubt that, they were all marked incomplete by a script from some random guy while we were in florida
[11:28] <ogra> i'm sure cjwatson would have liked to keep some of them open
[11:37] <elif> Hi cjwatson , I would like to know if its possible to package partman.udeb inside initrd so I don't have to setup a mirror with my modified partman udeb, thks in advance ?
[11:38] <elif> right now to test partman with modifications I need to setup a mirror, because my installation method is only by network (netboot).
[11:46] <dpm> hi ev, may I ask you to export translations from LP and add them to ubiquity before A2? This way everyone can start testing them.
[11:47] <ev> dpm: sure thing
[11:47] <dpm> ev, awesome, thanks
[11:53] <\sh> guys, did anyone saw this on lucid in the past few weeks: cron[4326]: segfault at 7f77c036a970 ip 00007f77c036a970 sp 00007fff81bd5bb8 error 4 in libnss_files-2.11.1.so[7f77e768b000+c000] ?
[11:53] <htorque> hello everyone! i need some help (not support) figuring out if this is some bug with plymouth worth filing:
[11:53] <htorque> http://img.xrmb2.net/images/787502.png - note the big gap after ureadahead finished, plymouth-debug.log: http://paste.ubuntu.com/556129/
[11:53] <htorque> this is a tailored 2.6.38-rc1 with no swap and apparmor disabled (, i get similar boot times with ubuntu's kernel
[11:57] <apw> htorque, does that graph say that plymouth is in an uninterruptible sleep ?
[11:58] <htorque> apw, the plymouthd bar it's slightly red, so that should mean it
[12:03] <htorque> i'll be off for an hour, i'll check irclogs, so if you need me to do something, go ahead :-)
[12:07] <apw> htorgue, not seeing that on my system here, am seeing other issues but not that long gap, i suspect plymouthd is printing the dots hense the blips
[12:08] <apw> the pause is likely something else
[12:15] <dholbach> do we have any idea how to fix bug 688732?
[12:22] <cjwatson> elif: I'm not going to change the initrds we ship to do that, if that's what you mean.  there's documentation in the d-i build system for how to add packages to it if you want to do it locally.
[12:25] <elif> cjwatson: I meant locally (my installation). I didn't find the docs you mentioned, could you point me ?
[12:26] <elif> cjwatson: its d-i docs ?
[12:28] <cjwatson> build/README in the debian-installer source package
[12:28] <cjwatson> easiest way is to list the names of udebs you want to include in build/pkg-lists/local
[12:29] <elif> cjwatson: thank you.
[12:40] <tumbleweed> dholbach: no idea where that file came from. Submitter's system was installed with 10.10, which used python-support for pywebkitgtk, it still does. That location is a python-central/dh_python2 location.
[12:43] <tumbleweed> dholbach: aah, 1.1.8-1 looks like the culprit
[12:45] <phenom> Any one here?
[12:46] <pitti> !ask | phenom
[12:46] <phenom> Not a question
[12:46] <phenom> Wubi installer is broke
[12:46] <phenom> Spits pyrun.exe says "no disk"
[12:46] <phenom> and then says Can not downloan metalink, and therefor the ISO
[12:46] <phenom> And dies
[12:47] <phenom> I assume it runs on win 7
[12:48] <apw> are you asking if it runs on win7 or saying you are running on something other than win7 (and assume it works on win7)
[12:48] <phenom> I'm saying, I tried to run it on win7 and it gives me those errors
[12:48] <phenom> and dies
[12:49] <phenom> it spits the pyrun.exe says "no disk" error about 15 or so times
[12:50] <phenom> and then continues through the installer, after I input the password if spits it can not download the metafile and therefor can not download the iso
[12:50] <cjwatson> which version?
[12:52] <phenom> rev 190
[12:52] <phenom> the one from http://www.ubuntu.com/desktop/get-ubuntu/windows-installer
[12:52] <cjwatson> ev: ^- can you look at that?
[12:53] <ev> cjwatson: yup
[12:58] <ev> phenom: can you pastebin %TEMP%/wubi-10.04.1-rev190.log
[13:06] <didrocks> kees: hey, if you can do a security review on https://bugs.launchpad.net/ubuntu/+source/dcmtk/+bug/702026, that will be nice :)
[13:10] <phenom> ev, pm
[13:12] <ev> phenom: thanks, I'll have a look after lunch
[13:13] <phenom> Sure, thanks
[13:13] <ari-tczew> didrocks: #ubuntu-hardened is good place for that question :)
[13:14] <didrocks> ari-tczew: I just ask for a security check on a MIR process, that can take some days, so I'm not sure I'll stay in #ubuntu-hardened there I think I hilighted the right person about it and it's done :)
[13:40] <htorque> apw: thanks for the feedback. i will keep an eye on it with mainline and ubuntu kernels once they are out - maybe it's just a misconfigured kernel on my end.
[13:40] <apw> htorque, ubuntu kernels will be a while as 32 don't boot on my test boxes
[13:42] <htorque> apw, yeah, i had to revert that commit about relocatable kernels you mentioned (it was not enough to just disable that option)
[13:42] <apw> i had to do that indeed, which worked for 64 bit, but my 32 bit box is failing to enable the timer
[13:42] <apw> and exploding
[14:17] <smoser> @pilot in
[14:18]  * dholbach hugs smoser
[14:22] <cjwatson> pitti: FYI, I'm wrestling with my last couple of bugs for the lucid SRU freeze ... expect uploads over the next hour or two
[14:22] <cjwatson> trying to make USB stick upgrades not suck
[14:25] <pitti> ack
[14:55] <ari-tczew> smoser: have you got upload access for main?
[14:55] <smoser> no
[14:55] <kklimonda> what's the process for dealing with regression-proposed bugs?
[14:55] <smoser> otherwise i would sponsor your changes. (i guess you're looking for sponsor for 705294)
[14:56] <kklimonda> good afternoon btw.
[14:56] <ari-tczew> hello kklimonda
[14:56] <ari-tczew> smoser: nope, I'm looking for sponsor for main
[14:56] <kklimonda> (the process after marking sru bug as verification-failed, and the new one as regression-proposed, and nominating it for release)
[14:57] <ari-tczew> smoser: then you're weak patch pilot if you don't have upload access for main
[14:57] <smoser> i agree i'm a weak patch pilot
[14:57] <kklimonda> ari-tczew: you were also a patch pilot other day
[14:57] <smoser> i go through the sponsor list and see if i can make job easier for others.
[14:57] <ari-tczew> kklimonda: yes
[14:58] <smoser> bug 705294
[14:59] <ari-tczew> smoser: what is wrong with above? ^^
[14:59] <smoser> ari-tczew, nothing. i just assumed thats what you had a fix for and were asking for a sponsor of.
[15:00] <ari-tczew> smoser: I still understand.
[15:00] <ari-tczew> don't understand *
[15:01] <ari-tczew> I'm sponsoring 2 bugs for udienz right now.
[15:01] <smoser> never mind then. i was confused.
[15:01] <ari-tczew> I'm looking for main sponsorship for 2 things which I reviewed.
[15:01] <smoser> ah.
[15:01] <ari-tczew> https://code.launchpad.net/~barry/ubuntu/maverick/computer-janitor/bug-665740/+merge/46039
[15:01] <ari-tczew> https://code.launchpad.net/~om26er/ubuntu/maverick/nautilus/nautilus-fix-630512-maverick/+merge/45048
[15:01] <ari-tczew> https://code.launchpad.net/~clint-fewbar/ubuntu/karmic/mysql-dfsg-5.1/mysql-sru-343870/+merge/42667
[15:02] <ari-tczew> update, 3 things
[15:02] <ari-tczew> and I don't understand why patch pilots didn't find main sponsor for these patches
[15:02] <pitti> doko_: do you know about the "pystack" gdb feature?
[15:10] <Chipzz> ari-tczew: well, for one, the "fix" for https://code.launchpad.net/~barry/ubuntu/maverick/computer-janitor/bug-665740/+merge/46039 looks OBVIOUSLY incorrect
[15:11] <Chipzz> you should fix the python-dbus package instead of working around a bug in it
[15:12] <barry> Chipzz: perhaps, but would that have too much impact for an sru?
[15:12] <ari-tczew> Chipzz: hehehe, you're looking for hole in the whole
[15:12] <ari-tczew> the subject is a response for core-dev
[15:13]  * Chipzz looks at his screen and tries to decipher what ari-tczew is saying
[15:13] <Chipzz> no offence meant, but your English is quite poor
[15:16] <ari-tczew> Chipzz: nobody is perfect, maybe you?
[15:17] <Chipzz> barry: there's the question of what you should fix in an SRU in the first place; ignoring wether that bug is a candidate or not, fact is you should try to keep the changes minimal, which among other things means trying not the fix the same issue in different ways; and since you most likely want to fix the issue in the development release too, and you want to do it the proper way there, I think the best thing to do would be to fix it in python-dbus
[15:17] <Chipzz> ari-tczew: sigh :p
[15:18] <Chipzz> ari-tczew: I was looking at your sentence for 10 seconds, trying to understand it. then I looked again. and then I gave up trying to figure it out
[15:18] <soren> I'm not sure why python-dbus should depend on dbus?
[15:18] <barry> btw, python-dbus depends on libdbus-1-3
[15:19] <barry> which makes sense, but i think soren has a point
[15:19] <barry> and libdbus-1-3 recommends dbus
[15:19] <Chipzz> I don't see why computer-janitor should depend on dbus actually
[15:20] <soren> Now that is a different matter. I don't know.
[15:20] <barry> Chipzz: because the core functionality is in a dbus service (in >=maverick)
[15:20] <asac> csurbhi: hey ... quick question. mkfs.btrfs has no -U option. are uuids not supported for btrfs?
[15:20] <Chipzz> barry: errr, I'm just making a wild guess here, but how about "No Scott"? :p
[15:21] <Chipzz> barry: you don't have every pygtk application depending on libgtk now, do you?
[15:21] <barry> Chipzz: now you're not making sense :)
[15:21] <Chipzz> barry: if your app talks to dbus via python-dbus, then the dependency is on python-dbus, not dbus
[15:22] <cjwatson> c-j also ships its own dbus service; it isn't merely a client
[15:23] <barry> Chipzz: i think it's a different case.  libgtk is a library but dbus is a service
[15:23] <Chipzz> cjwatson: then it's a matter of how the dbus service interfaces with dbus, isn't it?
[15:23] <cjwatson> at least some other packages that ship dbus system-services depend on dbus directly (e.g. consolekit)
[15:23] <cjwatson> there is clearly precedent
[15:23] <cjwatson> system-tools-backends
[15:23] <cjwatson> avahi-daemon, network-manager
[15:23] <cjwatson> etc.
[15:24] <Chipzz> barry: imo they're both bindings, which is why the 2 cases should be treated the same
[15:24] <barry> Chipzz: i think the analogy would be to libdbus though, not dbus
[15:24] <cjwatson> depending on dbus directly seems correct to me.  it's relying on the dbus daemon directly and the dependency should be direct.
[15:25] <cjwatson> I'm happy to sponsor that SRU as written
[15:25] <cjwatson> (and will do so shortly
[15:25] <cjwatson> )
[15:25] <barry> cjwatson: thanks.  Chipzz and ari-tczew thanks also for the feedback. :)
[15:26] <Chipzz> cjwatson: if you think it's correct, I'll stop arguing about it, but it still looks wrong to me
[15:26] <ari-tczew> Chipzz:  :) :) :)
[15:26] <Chipzz> but I have to go offline anyway
[15:26] <cjwatson> I think it's correct and that your analogy is faulty given the specifics of this package, yes
[15:26] <soren> Chipzz: They're not both bindings.
[15:26] <soren> Chipzz: dbus is the daemon.
[15:26] <cjwatson> if you were talking about libdbus, the analogy would be sound
[15:26] <cjwatson> but that's not (only) what's at issue here
[15:27] <Chipzz> cjwatson: my reasoning is that the dependency chain should likely be app -> python-dbus -> libdbus -> dbus
[15:27] <cjwatson> that reasoning is faulty, because this application uses dbus in ways other than via python-dbus
[15:27] <Chipzz> since it makes little sense to have an app linked against dbus (be it client or service) without having dbus available
[15:27] <cjwatson> specifically by shipping a dbus system-service
[15:27] <Chipzz> anyway gtg
[15:31] <pitti> Chipzz: think of optional plugins
[15:32] <pitti> Chipzz: e. g. bzr-gtk annouces commits over session dbus, but it's only a bonus feature; so bzr-gtk would certainly depend on python-dbus (to not crash), but not on dbus (since it works without)
[15:34] <soren> You can also use libdbus without the dbus daemon.
[15:34] <soren> upstart does, for instance.
[15:35] <cjwatson> right, and in any case inserting an extra dependency further down the stack has *more* risk of regressions, not less, so I'd argue it'd be less appropriate for an SRU even if it were correct (which I don't think it is)
[15:35] <pitti> *nod*
[15:35] <barry> cjwatson: right, that was my thinking too
[15:36] <doko_> mvo: ping http://launchpadlibrarian.net/61917866/buildlog_ubuntu-natty-i386.update-manager_1%3A0.145.10_MANUALDEPWAIT.txt.gz
[15:38] <doko_> siretart: ping
[15:40] <barry> so, here's an unrelated, but general question.  i've seen this a few times with packages i'm doing test builds with (latest example: python-webkit).  i branch the source from ubuntu:python-webkit, then bzr bd -S (or debuild -S).  dpkg-source exits w/status 255 because "Version number suggests Ubuntu changes, but Maintainer does not have Ubuntu address".  this is true, but what's the right way to handle this for local builds?  i've just
[15:40] <barry> been running update-maintainer before doing a local build, but why hasn't that already been done for a -XubuntuY version?
[15:41] <doko_> pitti: libreoffice-common: is this still true with the -2ubuntu2 version?
[15:41] <cjwatson> probably because the last person who changed it in Ubuntu doesn't have @ubuntu.com in their DEBEMAIL so dpkg-source didn't error out on that
[15:41] <cjwatson> for quick local builds, I usually do DEBEMAIL=something@else debuild ...
[15:42] <cjwatson> (I might mean debuild -eDEBEMAIL=something@else ..., I forget)
[15:42] <pitti> doko_: seems to be the same size as ubuntu1, according to https://launchpad.net/ubuntu/+source/libreoffice/1:3.3.0~rc3-2ubuntu2/+buildjob/2183350
[15:43] <barry> cjwatson: ah, i didn't realize dpkg-source looks at DEBEMAIL (not obvious from manpage afaict).  thanks
[15:44] <cjwatson> it was a hack to try to get people to DTRT in their uploads without impeding *too* many people's local builds when people get it wrong
[15:45]  * barry loves social change by technological hack :)
[15:45] <Laney> DEBEMAIL= debuild works, yeah
[15:45] <barry> yep, wfm, thanks!
[15:45] <Laney> it at least means that most uploaders remember, even if the contributor does not
[15:47] <cjwatson> my other dodgy hack along those lines is that I occasionally do debuild -ePATH=$HOME/fake-debconfpo:$PATH -S
[15:47] <cjwatson> where $HOME/fake-debconfpo is a directory containing only a symlink from debconf-updatepo to /bin/true
[15:47] <soren> Heh.
[15:47] <cjwatson> this is helpful in cases where packages call debconf-updatepo on build and I don't want them to (e.g. because I'm building for lucid on natty and gettext's default header has changed)
[15:48] <cjwatson> just about anything can be worked around if you try hard enough ...
[15:53] <JamesPage> zul, daviey, kirkland: who's picking up bugs for cobbler now its in archive?
[15:54] <zul> JamesPage: server team is already subscribed to the bugs so I guess all of us
[15:54] <kirkland> JamesPage: all of us :-)
[15:54]  * kirkland knuckle bumps zul
[15:54] <JamesPage> :-)
[16:06] <doko_> pitti: I see, -common has the images_*.zip for all styles, see bug #696527
[16:06] <pitti> doko_: aah, thanks
[16:06] <pitti> doko_: so I guess we'll need to keep that around for now, and just drop the -writer recommends for JDK?
[16:09] <cjwatson> pitti: casper and grub2 uploads in {lucid,maverick}-proposed, fixing sabdfl bugs ;-)
[16:10] <cjwatson> csurbhi: did you get anywhere with that milestoned util-linux bug?
[16:10] <csurbhi> cjwatson, i am still working on the installer btrfs thing
[16:10] <csurbhi> i will get at the bug soon and shall try to do it before Sat
[16:11] <doko_> pitti: yes, I'll do that.
[16:11] <pitti> doko_: danke sher
[16:11] <doko_> how urgent is this?
[16:11] <cjwatson> csurbhi: oh - as I said in yesterday's meeting, the lucid SRU freeze (for 10.04.2) is today
[16:11] <pitti> doko_: by alpha-2, I think (since currently we have a 62 MB oversizedness which we can't fix by langpack dropping)
[16:11] <cjwatson> should I find somebody else to look at it?
[16:12] <pitti> doko_: alternatively we can just unseed it for a2, and put it back later
[16:12] <csurbhi> cjwatson, i am not sure i will be able to finish by eod
[16:12] <csurbhi> but i can try it
[16:12] <cjwatson> ok, thanks
[16:12] <csurbhi> ok
[16:12] <csurbhi> since there is a patch to the bug already
[16:12] <cjwatson> let me know if somebody in a more western timezone needs to pick it up
[16:13] <pitti> cjwatson: (talking to folks at the hackfest ATM, will look at it in a bit)
[16:13] <csurbhi> cjwatson, no let me first try doing it
[16:13] <csurbhi> i will get back in an hour or two
[16:13] <csurbhi> if i think i cant
[16:14] <cjwatson> ok
[16:14] <doko_> pitti: ok, this seems to be doable. I'd like to avoid dropping -writer
[16:14] <cjwatson> pitti: np, thanks
[16:17] <doko_> pitti: just want to wait for the armel builds
[16:17] <pitti> sounds good
[16:19] <kees> didrocks: if you haven't already, please assign ubuntu-security to the mir, and I'll pick it up when I start work this morning :)
[16:20] <didrocks> kees: excellent, will do, thanks:)
[16:34] <doko_> Riddell: could you have a look at the telepathy-qt4 build failure?
[16:46] <Riddell> doko_: I'll add it to my todo list
[17:03] <achiang> kirkland: hi, can i bug you again?
[17:03] <kirkland> achiang: sure, hit me
[17:03] <achiang> kirkland: just wondering why i'm seeing this: http://chizang.net/alex/tmp/Screenshot.png
[17:04] <achiang> kirkland: and i do have kvm module loaded...
[17:04] <kirkland> achiang: natty?
[17:04] <kirkland> achiang: what is the output of 'kvm-ok' ?
[17:04] <achiang> maverick
[17:04] <kirkland> achiang: ^
[17:04] <achiang> kirkland: ah. says i don't have it enabled in BIOS
[17:05] <achiang> kirkland: so i'll go do that
[17:05] <achiang> thanks
[17:06] <hallyn> when exactly does <package>.postinst get called?  I assume it's after 'binary_arch: install' from debian/rules?
[17:08] <cjwatson> hallyn: well after - when the user calls dpkg --configure (perhaps via dpkg -i, perhaps via apt-get, etc.)
[17:09] <cjwatson> so on a completely different machine from that running debian/rules in most cases
[17:09] <hallyn> oh.   hm.
[17:10] <hallyn> so if files are being installed which should belong to a new groupname, if that groupname is created in the .postinst, is that good enough?  I was thinking the system would refuse to create files owned by nonexisted group
[17:11] <kirkland> achiang: yup
[17:12] <cjwatson> hallyn: if the files are being created at run-time (e.g. in the postinst, or when the program is run), then the postinst is good enough
[17:12] <cjwatson> (and Depends: adduser)
[17:12] <cjwatson> hallyn: if you're shipping these files in the .deb, then you need to run adduser in the preinst, and Pre-Depends: adduser
[17:12] <achiang> kirkland: hm, BIOS claims that VT-D and VT-X are turned on, yet kvm-ok disagrees
[17:13] <cjwatson> hallyn: http://www.debian.org/doc/debian-policy/ch-files.html#s-permissions-owners
[17:13] <achiang> kirkland: is there a better channel we could debug this in? seems a little OT for here
[17:13] <hallyn> cjwatson: thanks, that was my guess, except i had no idea about Pre-Depends
[17:14] <kirkland> achiang: either here, or #ubuntu-server, or #ubuntu-cloud;  i'm in all of these, it's okay in any of them, IMHO
[17:14] <pitti> cjwatson: ok, lucid SRU queue empty; need one reupload from Micah (mailed him), rest looked o
[17:14] <pitti> k
[17:14] <achiang> kirkland: how about #ubuntu-virt?
[17:14] <kirkland> hallyn: is this for kvm?
[17:14] <pitti> good night everyone!
[17:14] <cjwatson> pitti: yay, thank you
[17:14] <kirkland> achiang: #ubuntu-virt -> #ubuntu-cloud
[17:14] <achiang> ah
[17:14] <cjwatson> pitti: I'll do a CD build pass tomorrow
[17:15] <pitti> cjwatson: we have a hackfest group dinner now, so I'm afraid you or slangasek need to handle the other stragglers today
[17:15] <pitti> cjwatson: cool, thanks
[17:15] <kklimonda> what's the process for dealing with regression-proposed bugs?
[17:15] <kklimonda> (the process after marking sru bug as verification-failed, and the new one as regression-proposed, and nominating it for release)
[17:16] <pitti> kklimonda: by default, the previous uploader should upload a fix
[17:16] <pitti> if it's a serious regression, we can also remove a package from proposed
[17:16] <kklimonda> pitti: ok, thanks
[17:17] <kklimonda> pitti: I bump the version, add a new changelog entry and create source package in a way that displays both changelog entries in the changes file?
[17:17] <pitti> kklimonda: right, using debuild -vVersionInUpdates
[17:18]  * pitti needs to run now
[17:20] <hallyn> kirkland: yeah
[17:20] <hallyn> kirkland: this is why on first-ever qemu installs, /dev/kvm is owned by root :)  on second attempt, when we ask them to re-try it works fine :)
[17:20] <hallyn> (someone complained last week about the same thing, right?)
[17:26] <kirkland> hallyn: i've seen recent complaints;  is this something that got dropped in the last merge?
[17:26] <kirkland> hallyn: as i don't think we've seen this before that
[17:28] <hallyn> that's the weird thing, i don't think this ahs changed.  at least i don't remember playing with it.  but let me check the maverick sources
[17:29] <hallyn> you know, for all the compalints ppl have about compiz, one great thing about it is that vnc doesn't insist on redrawing every time i put a window over it or switch viewports
[17:33] <SpamapS> :)
[17:33] <hallyn> kirkland: hell - have you restarted the machine since installing kvm?
[17:33] <kirkland> hallyn: nope
[17:34] <hallyn> hah, THAT's it
[17:34] <SpamapS> cool.. they're going to film a movie on my street on Saturday
[17:34] <kirkland> hallyn: ?  really
[17:34] <hallyn> it's a udev rule, so next time it'll work jsut fine.
[17:34] <kirkland> hallyn: hmm, do we need to trigger a reload or something postinst?
[17:34] <hallyn> i'm just moving group creation to preinst
[17:34] <kirkland> hallyn: because "reboot your machine after installing kvm" is kinda silly
[17:34] <hallyn> :)
[17:34] <SpamapS> not cool ... I have to move my car off the street by 8am
[17:35] <hallyn> SpamapS: you shouldn't have a car, polluter
[17:35]  * hallyn njoys making CA jokes
[17:36] <SpamapS> No I don't pollute.. I only use 91 octane.. its clean right? ;)
[17:37]  * hallyn pulls on the brakes before heading into dangerous political territory
[17:37] <hallyn> instead i'll comment on the tiny 'bottomless' cup they gave me today
[17:38] <hallyn> bright side, coffee doesn't have tiem to get cold
[17:51] <hallyn> hm, i installed nmh (and also tried mailutils-mh), but scan is not being installed.  anyone familiar with this?  (on natty)
[17:52] <smoser> @pilot-out
[17:52] <udevbot> Error: "pilot-out" is not a valid command.
[17:52] <smoser> @pilot out
[18:00] <hallyn> oh, i see
[18:10] <ogra> wohoo
[18:10]  * ogra hugs seb128
[18:10] <ogra> thanks for RB
[18:10]  * ogra prays that it builds now
[18:10] <seb128> ogra, you're welcome
[18:36] <kees> slangasek: you mentioned Keybuk might have thought about global environment vars in upstart?
[18:42] <slangasek> kees: yes, it's something I recall discussing with him in the past
[18:42] <slangasek> I believe he thought about it harder than I did :)
[18:43] <slangasek> though we did talk about the role of pam in upstart and I believe we agreed that its role is "none"
[18:43] <slangasek> at least for the presently supported job types
[18:45] <bcurtiswx_> "src/Makefile.am: object `empathy-accounts-dialog.$(OBJEXT)' created both with libtool and without"  What does this build error mean?
[18:46] <kees> slangasek: right, I too view PAM and upstart and disjoint
[18:46] <kees> s/and/as/
[18:46] <kees> slangasek: but did anything come of his hard thinking, do you know?
[18:46]  * kees wants to set MALLOC_PERTURB_=85 just to see what happens...
[18:46] <slangasek> kees: nope, you'd need to check with him
[18:46] <slangasek> or with James
[18:47] <bryceh> kees, do you know of any recent kernel plumbing-layer changes that would have made apport start collecting xserver crashes once again?
[18:47] <kees> jhunt: do you know anything about possible way to set global env vars in upstart?
[18:47] <bryceh> (I'm pleased to see them, but the retracer is not handling them properly yet)
[18:48] <kees> bryceh: nope, but when it stopped, it was a mystery too, so maybe something changed with the toolchain.
[18:50] <kirkland> does anyone else running natty have a sustained load of pretty much exactly 1.00 at idle?  (note that I have 4 CPUs...)
[18:54] <cjwatson> slangasek: does that need to change when upstart starts supervising user sessions?
[18:54] <cjwatson> (lp:~canonical-scott/upstart/session-support)
[18:56] <SpamapS> kees: I've looked into it. upstart only copies things from the job's  env stanzas and its own special vars (UPSTART_EVENTS, JOB, etc).
[18:57] <SpamapS> kees: and things from the event
[18:57] <slangasek> cjwatson: I imagine so
[18:57] <slangasek> cjwatson: what does it mean to "supervise" a user session?  will upstart be handling the authentication?
[18:58] <kees> kirkland: your load came from that kernel thread (ps auwwx | grep " D ")
[18:59] <kirkland> kees: right
[18:59] <kirkland> kees: root       667  0.0  0.0      0     0 ?        D    Jan19   0:07 [ips-monitor]
[18:59] <kirkland> kernel guys: what is "ips_monitor" ?
[19:00] <directhex> tkamppeter, is there a better way to add a missing PPD to upstream openprinting other than "bug you about it"? I can't find a thing on the linuxfoundation-based site
[19:00] <kees> lsmod | grep ips  ?
[19:01] <cjwatson> slangasek: no idea, I know about the branch's existence but haven't really looked at its contents
[19:01] <SpamapS> slangasek: btw, is there anything you need from me on the statd/portmap SRU? I don't mind doing the backporting work.
[19:02] <cjwatson> I don't *think* it does auth - I think it's more about partitioning off chrooted and user jobs so that they can't interact with system jobs
[19:02] <tkamppeter> directhex, no. There is a page to add a printer, but not to upload a PPD. What PPD is that?
[19:02] <directhex> tkamppeter, two more kyocera ppds which, helpfully, aren't in their main ppd bundle
[19:02] <slangasek> SpamapS: the SRUs have been uploaded, please validate them? :)
[19:02] <SpamapS> slangasek: oh I didn't see that!
[19:03] <directhex> tkamppeter, bottom of http://www.kyoceramita.co.uk/index/products/download_centre.false.driver.FSC2126MFP._.EN.html
[19:04]  * SpamapS is about 2 hours behind on email..
[19:10] <ebroder> slangasek, cjwatson: my understanding was that "user sessions" was just about letting users have a ~/.upstart with jobs that could only run as them. i don't think they run under a PAM session or anything currently, though it seems like they probably should
[19:10] <ebroder> (that's what i remember seeing on the branch, anyway)
[19:12] <tkamppeter> directhex, is this one PPD (for yopur printer) or a series of PPDs?
[19:13] <directhex> tkamppeter, it's two ppds for two near-identical multifunction devices (only difference is the fax, and i don't think the ppd supports that anyway)
[19:16] <directhex> tkamppeter, seems they've been localized, so 6 pairs of PPDs for the FS-C2026MFP and FS-C2126MFP - where the only difference between the two is the product names in the PPD
[19:17] <directhex> -*Duplex None/Ninguno: "statusdict begin false setduplexmode false settumble end"
[19:17] <directhex> +*Duplex None/None: "statusdict begin false setduplexmode false settumble end"
[19:28] <slangasek> ebroder: so integration with pam there buys you: - kerberos/afs credentials for the job; - honoring of pam_limits; - incompatibility with pam_ck_connector
[19:31] <kees> SpamapS: is there any movement towards having a place for global env vars too?
[19:37] <SpamapS> kees: I've not discussed or heard anything about it. I was looking to see how we could take advantage of the kernel passing its cmdline to init in the env.
[19:37] <kees> ah-ha
[19:37] <SpamapS> kees: it would make perfect sense for it to end up in /etc/init.conf though
[19:37] <kees> SpamapS: are there plans for such a file?
[19:38] <SpamapS> it exists now
[19:38] <SpamapS> and must be 0 bytes
[19:38] <SpamapS> or rather, it can exist now
[19:39] <SpamapS> kees: so just have to parse the env stanza from there, and have upstart add that to things it copies into a new instances' environment.
[19:39]  * SpamapS just abused the apostrophe .. poor apostrophe
[19:39] <kees> "must be 0 bytes" ?
[19:40] <SpamapS> kees: yeah, it parses the file, but there are no allowed stanzas
[19:40] <kees> hahah best config file evar
[19:40] <SpamapS> might be possible to put comments in it. I'm parroting jhunt's statement that it must be empty there.
[19:41] <SpamapS> "you can configure it any way you like, as long as you leave it blank"
[19:41] <SpamapS> (paraphrased) -- Henry Ford
[19:43] <bcurtiswx_> if i wanted to check to see if a builder reaches a certain part of code, is there a code I can cause it to pause with an echo statement ?
[19:44] <directhex> tkamppeter, you know, there seem to be lots of models like this. i wonder if they have a unified ppd tarball anywhere
[19:45] <ebroder> slangasek: PAM integration couldn't get you credentials because it doesn't have access to any. that's only any good if you're running through the password stack
[19:45] <cjwatson> bcurtiswx_: 'echo foo; sleep 3600' or whatever?
[19:46] <cjwatson> why pause?  is this for a local build?
[19:47] <bcurtiswx_> cjwatson, http://paste.ubuntu.com/556278/ is my fail
[19:47] <slangasek> ebroder: I'm presuming that the job is being spawned from within a user login session, so the creds are already available in the environment and just need to be copied/preserved for use
[19:47] <bcurtiswx_> so i went to empathy-chat-window.c and a patch adds "#include empathy-indicator-manager.h" so it _should_ see it
[19:48] <bcurtiswx_> cjwatson, ^^
[19:48] <bcurtiswx_> im just trying to debug, see if it enters a ifdef with the header definitions
[19:49] <cjwatson> bcurtiswx_: you want gcc -E -dD
[19:49] <cjwatson> bcurtiswx_: that's not a missing #ifdef, though, that's an incorrect link line
[19:50] <sveinse> How I can start the pulseaudio daemon when not in X on maverick? I need sound, but the system is not running X, however I fail to start the PA daemon
[19:50] <bcurtiswx_> cjwatson, where is this done.. im using pbuilder
[19:50] <cjwatson> bcurtiswx_: any symbol used by empathy-chat-window.o must be placed *after* empathy-chat-window.o on the link line ('gcc -g -O2 -g -O2 -Wl,-Bsymbolic-functions -o empathy-chat ...')
[19:50] <sveinse> someone knows where and how PA is started during X11 user login?
[19:50] <cjwatson> pbuilder is irrelevant
[19:52] <sbeattie> bcurtiswx_: something wants to link against libgtk-x11-3.0; however -ltk-x11-2.0
[19:52] <sbeattie> is being linked against.
[19:53] <cjwatson> well, there's that too, but that isn't the cause of the errors after it
[19:54] <bcurtiswx_> hmm, this is where i'd be lost.  https://code.launchpad.net/~bcurtiswx/ubuntu/natty/empathy/empathy-2.91.5 is where i've pushed the patches.. i think you'd want to see debian/patches/20_libindicate.patch
[19:54] <bcurtiswx_> cjwatson, ^^ or where would I look to fix this
[19:57] <cjwatson> I imagine you need to add empathy-indicator.c to empathy_chat_SOURCES in src/Makefile.am (or something along those lines)
[19:57] <cjwatson> you need to link the objects you're using
[19:57] <cjwatson> (empathy-indicator-manager.c too)
[19:58] <bcurtiswx_> cjwatson, i have done that.. then I have to keep adding a whole bunch of .c and .h files to the chat_SOURCES
[19:58] <cjwatson> then you probably forgot to rerun automake
[19:59] <cjwatson> automake generates src/Makefile.in from src/Makefile.am
[19:59] <bcurtiswx_> cjwatson, oh, where would I  make it do that then?
[19:59] <cjwatson> get #ubuntu-desktop to help you integrate that into the package, they do this all the time and have their own patterns
[19:59] <cjwatson> mind you /usr/share/cdbs/1/rules/autoreconf.mk is supposed to do that
[20:00] <cjwatson> god knows, I can't stand cdbs :)
[20:00] <bcurtiswx_> i've been working on and off with seb128 and kenvandine
[20:00] <bcurtiswx_> actually..
[20:01] <bcurtiswx_> so somehow I have to get it to rerun automake after the patches are added
[20:01] <cjwatson> the way your package is set up, it should be doing that automatically already
[20:01] <bcurtiswx_> i'll ask in -desktop
[20:01] <cjwatson> anyway, if it were me, I would be very carefully looking through the build log to see if autoreconf is being run; then I would compare the failing gcc line printed in the build log with what's in src/Makefile.am and src/Makefile.in
[20:02] <cjwatson> and probably src/Makefile for good measure
[20:02] <cjwatson> if those three files don't match I'd go looking for problems in the generation code somewhere
[20:02] <nxvl> juliank: ping
[20:03] <tkamppeter> directhex, I must look into Kyocera's PPDs. If they do not have a unified tarball, I do not see any possibility to get the PPDs being added to distros or made auto-downloadable via OpenPrinting.
[20:03] <cjwatson> if they match, then I'd run the gcc line by hand with variations until it works, and then reintegrate those variations back into the patch to src/Makefile.am
[20:03] <cjwatson> debug it iteratively and be scientific about it
[20:04] <directhex> tkamppeter, it looks horribly manual right now. i mean, the PPDs are all properly licensed and redistributable, but who wants to go to every device's drivers page to grab a single ppd?
[20:04] <directhex> tkamppeter, there seem to be humans on their UK twitter account, i'll see if anyone responds
[20:06] <juliank> nxvl: pong
[20:06] <nxvl> juliank: i added some more info to Bug #704595, and i was wondering if you can give me some guidance to fix it, cause i have no experience with apt's code
[20:09] <juliank> bcurtiswx_: autoreconf should run after patches were applied, as dpkg applies the patches, and then debian/rules is run
[20:09] <bcurtiswx_> juliank, cjwatson, autoreconf does run
[20:10] <juliank> nxvl: I have no idea why apt fails
[20:11] <nxvl> juliank: mvo told me a while ago that was an auth issue, with the keyring and such, as it seems it's looking for a keyring inside the chroot, instead of the system chroot
[20:11] <nxvl> juliank: therefor failing
[20:12] <bcurtiswx_> juliank, cjwatson: as seen here http://paste.ubuntu.com/556287/
[20:12] <juliank> nxvl: It also doesn't work when copying the keyring
[20:12] <nxvl> juliank: oh, didn't tried that, have you?
[20:15] <juliank> bcurtiswx_: Looks correct to me.
[20:18] <ScottK> doko_ or barry: Any thoughts on http://launchpadlibrarian.net/62538907/buildlog_ubuntu-natty-i386.python3-defaults_3.2~rc1-1_FAILEDTOBUILD.txt.gz - It didn't fail when I test built it.
[20:28] <superm1> manjo, since you're doing testing on the SDP again with uefi, were you planning on testing both CD and USB installs this go around for natty?
[20:30] <manjo> superm1, yes
[20:31] <manjo> superm1, both works with this fix: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/702707
[20:32] <cjwatson> oh good, that fixed the other bug you reported then?
[20:32] <cjwatson> ah, you duped it
[20:43] <bdmurray> cjwatson: were you going to look at bug 701954?
[20:50] <ScottK> doko_ and barry: Try to install python3 on natty ....
[20:51] <cjwatson> bdmurray: that's what I get for not testing my fixes.  fixing properly
[20:55] <cjwatson> wow, damn, that's a lot of dups, sorry for not being caught up on bugmail
[20:57] <m_conley> cjwatson:  ping
[20:57] <cjwatson> m_conley: hi
[20:57] <cjwatson> (best to just say what you want up-front)
[20:58] <highvoltage> the ubuntu website says on http://www.ubuntu.com/project "Ubuntu is made for sharing. Use it, modify it, improve it, share it. Anywhere, any time and with any number of people all over the world. No licence required."
[20:58] <m_conley> cjwatson:  cool.  I'm trying to get Natty Alpha 1 up on VirtualBox4, and I keep running into this message during install, and then hanging:  http://i.imgur.com/K4AJ4.png  .  This happens regardless of whether or not I choose to install updates during install.  Any ideas or suggestions?
[20:59] <highvoltage> is it just me or is the "no licence required" part a bit icky?
[20:59] <cjwatson> m_conley: dunno, would need to see the log file it mentions
[20:59] <m_conley> cool, I'll try to fetch that...
[20:59] <cjwatson> it might be that a daily build would work better
[21:00] <cjwatson> the way the archive works, it's sometimes possible for changes after a milestone to break the milestone, unfortunately
[21:00] <m_conley> I started with daily builds, but I was having an even harder time getting those ones up on VirtualBox
[21:00] <mjr> highvoltage, I'm not sure if it's icky, but it's technically incorrect ;)
[21:00] <m_conley> with even more brutal errors (scary OS numbers and stuff on boot, then hang)
[21:00] <cjwatson> "no licence required for use" would be correct
[21:00] <cjwatson> well, no further licence
[21:00] <cjwatson> or something
[21:01] <cjwatson> I know what it means but it could use some wording that's similarly concise and friendly but actually true
[21:01] <highvoltage> ore even "no license costs" would be better imho
[21:01] <cjwatson> m_conley: generally it's useful to give the exact error messages :-)
[21:01] <m_conley> cjwatson:  I understand.  Give me a few minutes, and I'll supply it.
[21:01] <cjwatson> the scary OS numbers might happen to be ones I can help with
[21:02] <m_conley> cjwatson:  gotcha.
[21:02] <cjwatson> (btw, about to finish for the evening; mail is good though ...)
[21:02] <m_conley> cjwatson@canonical?
[21:02] <cjwatson> or else hang around and I'll reply to messages when I'm back
[21:02] <cjwatson> yeah
[21:02] <m_conley> k
[21:03] <m_conley> cjwatson:  I have your numbers
[21:03] <m_conley> cjwatson:  1 min
[21:04] <m_conley> cjwatson:
[21:04] <m_conley> http://imgur.com/nZH7b
[21:04] <m_conley> this occurs on boot.
[21:05] <cjwatson> ok, you need to talk to kernel folks about that
[21:05] <cjwatson> probably
[21:06] <m_conley> cjwatson:  which kernel folks would you suggest?
[21:06] <cjwatson> I don't know their internal structure - start with #ubuntu-kernel
[21:06] <m_conley> cjwatson:  will do.  Thanks for you help, and good evening!
[21:06] <cjwatson> I imagine they'll need more information than that, but will be better placed than I to suggest how to get it
[21:07] <cjwatson> (I always use kvm, for starters ...)
[21:07] <highvoltage> I had that too with i386, but not amd64, I'd guess that the kernel team will probably be aware of that by now
[21:07] <highvoltage> (under kvm)
[21:07] <m_conley> highvoltage:  oh, nice - maybe I'll try the 64.  Thanks.
[21:08] <superm1> manjo, ah great to hear :)
[21:15] <manjo> superm1, any news from your bios team regarding uefi issues on clients ?
[21:19] <ebroder> slangasek: oh, interesting. that would imply much tighter env integration between upstart and the user's session than currently exists, but would be kind of cool
[21:23] <ScottK> doko_ and barry: I filed Bug #705619
[21:24] <SpamapS> cjwatson: in discussing this with jhunt, we agreed that we'd like to get your input on this merge proposal which restores upstart's re-exec code: https://code.launchpad.net/~clint-fewbar/ubuntu/natty/upstart/restore-re-exec-code/+merge/45295
[21:24] <SpamapS> cjwatson: in bug #672177 keybuk agreed this is "the right thing to do"
[21:27] <cr3> who's the upstart maintainer these days?
[21:27] <SpamapS> jhunt
[21:28] <SpamapS> tho keybuk will still tend to it on some level I hope :)
[21:37] <barry> ScottK: thanks, i'll take a look at that
[21:37] <ScottK> barry: Thanks.
[21:51] <seb128> does order of .c files in makefile.am makes a difference?
[21:51] <seb128> like
[21:51] <seb128> empathy_chat_SOURCES =
[21:51] <seb128> 	empathy-chat.c \
[21:51] <seb128> 	empathy-indicator-manager.c
[21:52] <seb128> does it matter if the empathy-chat.c is at the end or not?
[21:52] <seb128> well the list does end with a 	$(NULL)
[21:52] <seb128> trying to debug bcurtiswx_'s issue
[21:52] <seb128> he gets
[21:53] <seb128> am_empathy_chat_OBJECTS = empathy-about-dialog.$(OBJEXT) \
[21:53] <seb128>         empathy-chat-manager.$(OBJEXT) empathy-chat-window.$(OBJEXT) \
[21:53] <seb128>         empathy-invite-participant-dialog.$(OBJEXT) \
[21:53] <seb128>         empathy-chat.$(OBJEXT) empathy-indicator-manager.$(OBJEXT) \
[21:53] <seb128>         empathy-indicator.$(OBJEXT)
[21:53] <seb128> but the build line stops the object list at empathy-invite-participant-dialog.o
[21:53] <seb128> on http://paste.ubuntu.com/556278/
[21:53] <seb128> well to empathy-chat.o rather
[22:03] <ari-tczew> cjwatson: what do you think, shall we wait for lilo 23 in Debian?
[22:14] <janimo> seb128, the object file that contains the missing symbol should be after the object file that uses it
[22:15] <seb128> janimo, well that's coming from a empathy_chat_SOURCES definition
[22:15] <janimo> I think it is due to the new linking flag, gold style
[22:15] <seb128> so the source files order determine the objects order which needs to be right?
[22:15] <janimo> being more restricitve
[22:15] <janimo> yes
[22:15] <janimo> maybe upstream did not test with our flags or with gold linker?
[22:19] <seb128> janimo, it's a distro patch a contributor tries to get build on a new version
[22:19] <seb128> they did change their makefiles though
[22:20] <seb128> it was not clear that the order of the sources was important for the build
[22:20] <seb128> thanks
[22:25] <janimo> seb128, you're welcome. Actually the order of object files is important for the linker, and that is a search and replace of the source file list in the makefile
[22:50] <Riddell> TheMuso: how used is at-spi compared to at-spi2?
[22:51] <TheMuso> Riddell: at-spi long term is being deprecated.
[22:51] <TheMuso> Riddell: however atm at-spi performs a little better than at-spi2, which will likely be solved in coming months.
[22:51] <TheMuso> Riddell: I am hoping at-spi2 can be used for natty, working with upstrea to fix a few show stoppers atm.
[23:18] <Riddell> TheMuso: could you read over this quickly when you have a moment?  jono wanted a report https://wiki.kubuntu.org/QtAccessibility
[23:19] <TheMuso> Riddell: Sure.
[23:21] <TheMuso> Riddell: Looks good.
[23:22] <Riddell> great, thanks TheMuso
[23:22] <TheMuso> np
[23:23] <jono> Riddell, TheMuso thanks for your work on this, much appreciated
[23:23] <TheMuso> jono: np


[16:30] <tyhicks> hello
[16:30] <tyhicks> #startmeeting
[16:30] <meetingology> Meeting started Mon Dec  5 16:30:56 2016 UTC.  The chair is tyhicks. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:30] <meetingology> Available commands: action commands idea info link nick
[16:30] <tyhicks> The meeting agenda can be found at:
[16:31] <tyhicks> [LINK] https://wiki.ubuntu.com/SecurityTeam/Meeting
[16:31] <mdeslaur> \o
[16:31] <tyhicks> [TOPIC] Weekly stand-up report
[16:31] <tyhicks> jdstrand: you're up
[16:31] <chrisccoulson> hi :)
[16:31] <tyhicks> jdstrand: hey - you're up if you're ready
[16:32] <jdstrand> hey
[16:32] <jdstrand> I didn't get to anything I planned to last week except for review tools updates. Everything else was surrounding PR reviews, --classic, personal, bugs and base declaration updates. as such, this week is pretty much the same as last week:
[16:32] <jdstrand> follow up on dbus-app interface for snappy
[16:32] <jdstrand> snappy reviews
[16:32] <jdstrand> start looking at network-namespace interface
[16:32] <jdstrand> seccomp arg filtering policy as have time
[16:32] <jdstrand> that's it from me
[16:32] <jdstrand> mdeslaur: you're up
[16:33] <mdeslaur> I'm in the happy place this week
[16:33] <mdeslaur> I'm working on nss updates, that's about it as I go on vacation next week except for monday
[16:33] <mdeslaur> next!
[16:33] <tyhicks> I'm in the community role this week
[16:34] <tyhicks> I'm finishing the second part of the seccomp logging changes for snappy
[16:34] <tyhicks> that's the "complain mode" support
[16:34] <tyhicks> I still need to get to some eCryptfs issues
[16:34] <tyhicks> that includes the inode timestamps issue (LP: #1636890) and a crypto api usage issue
[16:35] <tyhicks> that's it for me
[16:35] <tyhicks> jjohansen: are you around?
[16:35] <tyhicks> sarnold: go ahead and we'll circle back if jjohansen gets here
[16:36] <sarnold> I'm on bug triage this week
[16:36] <sarnold> I didn't get much done on non-cve-triage last week, so just replay all that here :) libsmbios mir, starting swift-s3-something mir
[16:36] <sarnold> and I'm pretty sure I'm off friday, so short week
[16:37] <sarnold> that's it for me, chrisccoulson?
[16:37] <tyhicks> sarnold: is there anything left for you to do on that apt bug?
[16:37] <sarnold> tyhicks: oh! I forgot that one..
[16:37] <chrisccoulson> I need to do the oxide 1.19 release this week
[16:37] <sarnold> tyhicks: hopefullly apt has been let into the build queue by now, if it has, then i'll test it.
[16:37] <chrisccoulson> fingers crossed there will be no mozilla updates this week
[16:37] <sarnold> chrisccoulson: heh, didn't you just do one? :)
[16:38] <chrisccoulson> Other than that, I'm currently working on bug 1637190, and I need to do a review too
[16:38] <chrisccoulson> That's me done
[16:38] <tyhicks> sarnold: it is still in the trusy unapproved queue
[16:38] <chrisccoulson> sarnold, yeah ;)
[16:38] <tyhicks> thanks chrisccoulson
[16:38] <ratliff> I think I'm up
[16:38] <tyhicks> you are :)
[16:39] <ratliff> I'm on CVE triage this week
[16:39] <ratliff> I'm working on a ghostscript regression (LP: #1647276)
[16:40] <ratliff> that is it for me
[16:40] <sarnold> why do I suddenly want a pepsi..?
[16:40] <tyhicks> :)
[16:40] <tyhicks> [TOPIC] Highlighted packages
[16:40] <tyhicks> The Ubuntu Security team will highlight some community-supported packages that might be good candidates for updating and or triaging. If you would like to help Ubuntu and not sure where to start, this is a great way to do so.
[16:40] <tyhicks> See https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures for details and if you have any questions, feel free to ask in #ubuntu-security. To find out other ways of helping out, please see https://wiki.ubuntu.com/SecurityTeam/GettingInvolved.
[16:41] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/firebird2.5.html
[16:41] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/netty-3.9.html
[16:41] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/privoxy.html
[16:41] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/node-connect.html
[16:41] <tyhicks> http://people.canonical.com/~ubuntu-security/cve/pkg/libpgf.html
[16:41] <tyhicks> [TOPIC] Miscellaneous and Questions
[16:41] <tyhicks> Does anyone have any other questions or items to discuss?
[16:42] <tyhicks> jdstrand, mdeslaur, sarnold, ChrisCoulson, ratliff: Thanks!
[16:42] <tyhicks> #endmeeting
[16:42] <meetingology> Meeting ended Mon Dec  5 16:42:14 2016 UTC.
[16:42] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2016/ubuntu-meeting.2016-12-05-16.30.moin.txt
[16:42] <mdeslaur> thanks tyhicks
[16:43] <ratliff> thank you tyhicks!
[16:43] <jdstrand> thanks tyhicks :)
[16:44] <sarnold> thanks tyhicks!
[19:01] <slashd> Hi, Is there a mtg today "Developer Membership Board" ?
[19:03] <rbasak> o/
[19:04] <rbasak> I'm afraid I don't think we'll have quorum today.
[19:04] <rbasak> Most DMB staff who are also Canonical employees are sprinting this week.
[19:04] <fossfreedom_> oh dear!
[19:05] <micahg> o/
[19:05] <HEXcube> Uh.. Oh..
[19:05] <slashd> rbasak, Is it possible to get +1/-1 via email instead of waiting for next meeting ? just asking if possibe
[19:05] <slashd> I think I already saw that in the past (if you think it is applicable)
[19:07] <rbasak> slashd: I think most prefer IRC, but I believe ML-only has been offered (and done) before.
[19:07] <slashd> rbasak, ok was only proposing since I don't think there is much mtg in 2016 right ?
[19:08] <slashd> it starts back in "January 16th 2017" from what I see
[19:08] <rbasak> I had proposed that we skip the 19 Dec meeting as I didn't think there would be much attendance.
[19:08] <rbasak> Perhaps we can re-instate it if there's demand and we can check that DMB members will be available.
[19:09] <rbasak> Or, indeed, exceptionally do one next week or somethin ginstead.
[19:10] <slashd> rbasak, ok I'm really up to any propositions (email, next week, 19dec, ...) and worst case I will re-apply in Jan 2017
[19:10] <rbasak> I'm quite happy to make accomodations, but of course I'm here and the others who would need to show up to that aren't here :-/
[19:10] <slashd> rbasak, yeah this is why I thought that email would be a good alternative, but again worst case I will re-re-apply in 2017 lol
[19:11] <rbasak> I can try to ask around tomorrow as most of the Canonical DMB staff not here right now around in the same building as me tomorrow.
[19:12] <rbasak> Who was the other applicant?
[19:12] <fossfreedom> hi - that would be me
[19:12] <rbasak> o/
[19:12] <fossfreedom> :)
[19:13] <rbasak> I guess broadly the options are: 1) defer to another IRC meeting; 2) defer to ML
[19:13] <fossfreedom> sorry - ML ?
[19:13] <slashd> mailling list
[19:13] <rbasak> Mailing list (devel-permissions@)
[19:13] <fossfreedom> k
[19:14] <rbasak> Another IRC meeting could be 12th, 19th, another date, or January.
[19:14] <rbasak> And time to be determined.
[19:14] <rbasak> slashd, fossfreedom: if we followed that path, what would be your availability?
[19:14] <fossfreedom> hmm - kind of a problem maybe for Ubuntu Budgie?
[19:14] <slashd> rbasak, ok 12th and 19th would work for me
[19:14] <fossfreedom> I will try to make myself available anyhow
[19:15] <rbasak> OK, what sort of times? 1900 UTC like this one? 1500 UTc/
[19:15] <rbasak> UTC?
[19:15] <fossfreedom> would prefer if poss 1900UTC
[19:15] <slashd> 19:00 UTC is fine for me
[19:16] <rbasak> OK. I'll try to ask the others tomorrow if they're willing to do 12th or 19th, 1900UTC.
[19:16] <fossfreedom> thnx
[19:16] <slashd> thanks rbasak
[19:16] <rbasak> If we can get a quorate number available, we could do that.
[19:16] <slashd> much appreciated
[19:16] <fossfreedom> cheers
[19:17] <rbasak> I can currently do the 12th at 1900, but not the 19th at 1900.
[19:17] <rbasak> micahg: how about you?
[19:17] <micahg> I think that's fine
[19:17] <micahg> either one
[19:18] <slashd> 12th 1900 works for me
[19:20] <rbasak-lag> My main connection seems to have died :-(
[19:20] <rbasak-lag> 19:17 <rbasak> I can currently do the 12th at 1900, but not the 19th at 1900.
[19:20] <rbasak-lag> 19:17 <rbasak> micahg: how about you?
[19:20] <rbasak-lag> Is what I saw last.
[19:21] <micahg> [13:17] <micahg> I think that's fine
[19:21] <micahg> [13:17] <micahg> either one
[19:21] <micahg> [13:17] <slashd> 12th 1900 works for me
[19:21] <sarnold> rbasak-lag: < micahg> I think that's fine < micahg> either one < slashd> 12th 1900 works for me
[19:21] <rbasak-lag> Thanks :)
[19:21] <rbasak-lag> OK, shall we leave it there then? I'll report back tomorrow.
[19:21] <fossfreedom> rbasak - quick question ... on a related matter - we need someone to review and feedback our sponsors ubuntu-budgie-meta package - I see the ubuntu sponsors team are quite backed up at the moment.  Anyone available that you know that can review?  We believe this is one of the last steps before asking for ISOs production (probably).
[19:22] <slashd> rbasak-lag' works for me, let's reconvene tomorrow with final decision
[19:23] <rbasak-lag> I'm afraid most of the people who could review that are busy this week. I would, but I'm sorry I'm not confident reviewing that.
[19:23] <rbasak-lag> slashd: great. Thanks! And sorry for the trouble.
[19:23] <micahg> fossfreedom: have you asked in #ubuntu-motu?
[19:23] <fossfreedom> haven't as yet - will try.
[19:24] <slashd> rbasak-lag, don't be sorry I totally understand, I was myself in a sprint 2 weeks ago.
[19:24] <HEXcube> Anytime between 12th 15:00UTC and 19:00 UTC
[19:24] <slashd> rbasak-lag, enjoy Seville


[14:23] <throstur> okay, so I've been "repacking texts" for about 4 hours now, how do I do a full "re-checkout"?
[14:28] <throstur> noone? aw man, I guess I'll wait another 5-6 hours