[02:57] <poolie> is there some trick necessary to make pbuilder use a mirror when creating the chroot?
[02:58] <poolie> other than putting it in pbuilderrc
[02:58] <lifeless> IIRC yes, patch it to not splat over the variables
[02:58] <lifeless> I *think* I filed the bug about it
[03:01] <poolie> i don't see one in https://bugs.launchpad.net/ubuntu/+source/pbuilder
[03:01] <poolie> maybe it's only in debian?
[03:05] <lifeless> huh, maybe my memory is on the fritz
[03:05] <StevenK> What? That is madness
[03:05] <SpamapS> poolie: its dead simple to make sbuild use a mirror
[03:06] <SpamapS> poolie: mk-sbuild --debootstrap-mirror=URL
[03:06] <poolie> so you're suggesting i should avoid it by using sbuild instead?
[03:07] <StevenK> I thought there was a --mirror option for pbuilder
[03:08] <poolie> i have that set but it seems to only set the mirror inside the chroot, not the one that will be used by debootstrap
[03:08] <poolie> imbw
[03:08] <StevenK> --debootstrap-mirror, IIRC
[03:08] <lifeless> export MIRRORSITE=http://mirror.internode.on.net/pub/debian/
[03:08] <poolie> yes i have that in pbuilderrc
[03:08] <lifeless> looks like the bug was fixed - thats what I have currently [in a pbuilder script I haven't used in since moving ...]
[03:11] <poolie> ok, pbuilder works, but pbuilder-dist clobbers it
[03:19] <hyperair> poolie: ping
[03:20] <hyperair> poolie: regarding the banshee --debug log you posted, did it start working after you tried the patch, or without the patch?
[03:21] <poolie> hello
[03:21] <hyperair> https://bugs.launchpad.net/bugs/823723 <-- this oen
[03:22] <hyperair> although the bug for the --debug crash is https://bugs.launchpad.net/bugs/823956
[03:22] <poolie> sorry which patch?
[03:22] <hyperair> the patch provided in the latter bug
[03:23] <hyperair> on mono-addins?
[03:24] <poolie> no, i' hadn't applied that, so apparently the crash is intermittent or environment dependent
[03:24] <poolie> or something
[03:24] <hyperair> ah, i see.
[03:24] <hyperair> i'll post that in the bug
[03:44] <poolie> could i get a review on https://code.launchpad.net/~mbp/ubuntu/oneiric/gnupg2/815190-assertion/+merge/71140
[06:39] <RAOF> cjwatson: Should your debian-installer SRU to lucid have a bug report associated with it?  It looks sane apart from that.  Is there a different policy for d-i?
[06:41] <SpamapS> heh
[06:41] <SpamapS> I was just getting around to looking at it ;)
[06:41] <SpamapS> and was going to ask the same thing. :-P
[06:42] <SpamapS> RAOF: since you're just near EOD .. but I'm near EO-ability-to-keep-eyes-open .. I'll let you take it from here. :)
[06:42]  * SpamapS passes out
[06:42] <RAOF> Have fun in your exhausted dreams!
[07:04] <hyperair> does anyone know how apport.hookutils.attach_gconf(pkg) works?
[07:04] <hyperair> does it just look at /apps/<pkg>?
[07:04] <pitti> Good morning
[07:05] <hyperair> morning, pitti
[07:05] <hyperair> do you know if apport looks into /apps/<pkg> or into any given schemas installed by a package <pkg>?
[07:06] <pitti> mdeslaur: seems we still have some rdepends: gnome-codec-install, checkbox-gtk, update-notifier, gnome-system-log
[07:06] <pitti> mdeslaur: weird that a suid binary needs gksu or pkexec in the first place?
[07:06] <chrisccoulson> hi pitti
[07:06] <pitti> hyperair: which schemas?
[07:07] <pitti> hyperair: oh, I think we don't have a gsettings equivalent of "changed gconf keys" yet
[07:07] <hyperair> pitti: i was actually looking into https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/823726
[07:07] <hyperair> which is a little tricky, because banshee's package name is banshee, but gconf key is /apps/banshee-1.
[07:07] <pitti> hyperair: "ubuntu-bug 17978"?
[07:08] <pitti> that package indeed doesn't exist :)
[07:08] <hyperair> eh?
[07:08] <hyperair> what?
[07:08] <pitti> that's what the description says
[07:08] <hyperair> ._.
[07:08] <hyperair> it's that simple?
[07:08] <RAOF> Morning pitti, chrisccoulson :)
[07:08] <hyperair> pitti: no wait, you can ubuntu-bug a pid.
[07:09] <hyperair> pitti: it could very well be banshee's pid
[07:11] <chrisccoulson> hi RAOF
[07:15] <pitti> hyperair: ah, right
[07:15] <pitti> hyperair: apport.hookutils.attach_gconf(report, 'banshee-1')
[07:15] <pitti> hyperair: so I suppose the banshee package hook calls that, which fails
[07:16] <pitti> (sorry, don't have it installed ATM)
[07:21] <RAOF> pitti: Just to confirm again - the packages we accept into foo-proposed should have a changes file containing all the entries from the current package in foo-updates/foo (depending on whether there's a foo-updates package yet or not), right?
[07:21] <pitti> RAOF: correct
[07:30] <infinity> Wait, what?
[07:30] <infinity> Why would it need a changes file detailing changes from pervious versions?
[07:31] <pitti> so that people who have only -updates actually see all the changes in the .changes, update-notifier, etc.
[07:31] <pitti> and for a more technical reason, that the current .changes refers to all bugs which need verification in -proposed
[07:32] <pitti> i. e. if you stack a -proposed upload on top of a previous -proposed upload, the second one needs to have both
[07:32] <pitti> ... changelogs
[07:32] <infinity> But that's now what he said.
[07:32] <pitti> "from the last -updates upload on"
[07:32] <infinity> He said it should have all the changes from previous -updates uploads.
[07:33] <pitti> oh, I mis-attributed the "on"
[07:33] <pitti> RAOF: right, so see above
[07:33] <infinity> Okay, with the "on" tacked on the end, it makes more sense. :P
[07:33] <pitti> RAOF: it shold only include pending stuff in -proposed, not stuff which is already in -updates
[07:33] <pitti> or s/from/since/
[07:33] <RAOF> pitti was reading it as I intended.
[07:34] <RAOF> I just didn't ask the question properly :)
[07:34] <infinity> RAOF: As for the d-i case you mention above, d-i rebuilds don't necessarily address bugs directly (at least, not one that bumps a kernel ABI, like the recent one), think of them like linux-meta uploads, which also don't need bugs associated with them.
[07:35] <infinity> Alternately, I suppose they could reference every bug that the underlying d-i and/or kernel bits fixed, but that seems a bit redundant.
[07:35] <RAOF> They therefore also need no verification?
[07:35] <pitti> *nod*, d-i rebuilds are usually accepted without much of a changelog
[07:35] <pitti> they just usually don't get tested
[07:36] <pitti> and thus tend to stay aroud in -proposed forever
[07:36] <RAOF> How do we track whether they are tested or not if there's no associated bug?
[07:36] <infinity> They stick around in proposed often until we get around to testing them for a point release.
[07:36] <infinity> RAOF: They get tested with image testing for point releases, often not until then.
[07:37] <infinity> (And we move them up -updates as part of the release process, if required)
[08:41] <brendand> how can i get a list of all packages that *should* be installed in oneiric?
[08:41] <brendand> i say this because i recently found that i mysteriously had a ton of packages missing
[08:41] <brendand> g-c-c, update-manager, command-not-found and several more
[08:42] <brendand> and now i can't login and i'm wondering if it's because i'm missing something important
[08:44] <RAOF> ubuntu-desktop should pull in basically everything you'd have.
[08:45] <mvo> brendand: you can run "sudo apt-get install --fix-policy" to ensure you have all recommends installed
[08:45] <mvo> brendand: especially during the devel release it may happen that recommends get missing
[08:46] <brendand> mvo - you wouldn't happen to be having problems logging in on an up-to-date oneiric system?
[08:51] <brendand> did both those steps, still no luck
[09:16] <wendar> slangasek: the non-main packages added are the ones requested in the ubuntu-devel mailing list
[09:17] <wendar> slangasek: I figure we'll do another round of discussion on the list with the question "do we care about these enough to promote them to main?"
[09:34] <tjaalton> alpha3 installer crashed, does the daily image work?
[09:38] <tjaalton> that would be a no, since only oversized  powerpc image exists
[09:44] <Quintasan> Is anyone aware that flashplugin-installer update brok flash?
[09:48] <Quintasan> hmmm
[09:48] <Quintasan> Few users report flash missing after update, but when I reinstalled it, it worked
[10:00] <cjwatson> RAOF: I haven't normally bothered for d-i updates, since they're so formulaic and generally just go with kernel ABI changes
[10:00] <cjwatson> SpamapS: ^-
[10:01] <cjwatson> ah, now I read more of scrollback ...
[10:18] <ev> anyone mind terribly if I split camerabin{,2} out of gstreamer0.10-plugins-bad?
[10:19] <ev> I'd like it for ubiquity without the mountain of deps that come with the rest of the package
[10:20] <directhex> is that the package which pulls in DECnet support, for all loyal PDP11 users?
[10:23] <ev> directhex: the very same!
[10:23] <directhex> but what about the pdp11 port of ubuntu?
[10:25] <ev> I'm afraid I'm too busy porting Ubuntu to the AS/400 to deal with any PDP11 concerns.
[11:10] <sbte> Hi, I was just asked to sign the Canonical contributor agreement. Do I really have to print it and scan it back, or can i just type it out and copy my signature in?
[11:19] <jjardon> Hi, Is evolution compiled with gnome-online-account support in oneiric?
[11:22] <seb128> jjardon, no, but thanks for pointing it, we will fix that
[11:22] <jjardon> seb128: ok, thanks!
[11:24] <jjardon> seb128: also, seems that gnome-contacts is still not packaged
[11:41] <seb128> jjardon, right, it's on our list, do you know if it's going to be part of GNOME 3.2?
[11:41] <seb128> jjardon, it got only 2 tarballs and no update for over 5 weeks
[11:47] <jjardon> seb128: thats probably because alex was in holidays
[11:48] <jjardon> seb128: the plan is that It will be part of 3.2, yes : https://live.gnome.org/ThreePointOne/Features/Contacts
[11:48] <seb128> ok
[11:49] <seb128> jjardon, well I know if was listed there, but a new components which only got 2 tarball when we are close from freeze times doesn't give confidence to be shipped
[11:49] <seb128> jjardon, it's also that it required vala 0.13 and we were still on 0.12 until recently
[11:49] <seb128> jjardon, but I will have a look to it
[11:50] <jjardon> seb128: I'll try to ask alex about the current status
[11:50] <seb128> jjardon, thanks
[11:58] <seb128> ev, doing a separate camerabin gst binary will not solve your issue
[11:58] <ev> seb128: oh?
[11:58] <seb128> ev, you will not get that codec set source promoted
[11:58] <seb128> well you can try
[11:58] <ev> set source promoted? I don't follow.
[11:58] <seb128> but it's a pack of unmaintained and buggy codecs, I doubt mir will ack it
[11:58] <ev> oh
[11:58] <seb128> ev, you can't have a binary in main for a source in universe
[11:59] <seb128> if you need that binary you will need to promote the source
[11:59] <seb128> the way to go is to distro patch that code to good as we do for some of the stuff empathy video call needs
[11:59] <seb128> it's annoying to maintain though
[12:00] <ev> what code? To be clear, I'm layering on top of camerabin2, skipping the Cheese stuff entirely.
[12:00] <ev> ah
[12:00] <seb128> ev, well what we need is camerabin to be in the good source
[12:00] <ev> right
[12:00] <ev> okay
[12:01] <ev> thanks for the spot
[12:01] <seb128> yw
[12:01] <mdeslaur> pitti: pkexec is the suid binary...
[12:01] <mdeslaur> pitti: hrm...apport also still uses gksu
[12:06] <pitti> mdeslaur: oh, for the root_command_output() stuff, right
[13:13] <ttx> wendar: http://tlohg.com/building-a-consistent-hashing-ring-part-1 (and subsequent parts)
[13:19] <doko> tkamppeter, about the icc-profiles MIR. you know that this package is in multiverse?
[13:21] <pitti> doko: he mentioned he wants it promoted to restricted
[13:24] <doko> pitti: not in the report. and do we want to have it in restricted? my guess is that it maybe would be better to split it into a free and non-free package. ubuntu doesn't have the absolute requirement of shipping in the preferred form or editing, afaik
[13:26] <pitti> doko: I think it's meant to be installed on demand, so it doesn't matter much whether it's in restricted or multiverse
[13:27] <pitti> doko: oh, it's missing source? depends on the library then
[13:27] <pitti> s/library/license/
[13:27] <pitti> if it's GPL and doesn't have preferred form of modification, it's a license violation, and we can't ship it at all in theory
[13:27] <pitti> multiverse vs. restricted doesn't matter much there
[13:30] <pitti> tseliot: I still have a WI "In jockey, display new X drivers from x-updates ppa"
[13:30] <pitti> tseliot: I understand you want to upload the -updates stub packages to proper ubuntu now
[13:30] <pitti> tseliot: so I suppose this WI shold be changed to "display new X drivers in -updates packages"?
[13:34] <johnt> hello folks, can anyone help with a quick preseed question?
[13:34] <cjwatson> johnt: probably
[13:35] <tkamppeter> doko, yes, does it not go from Multiverse to Restricted with a MIR then?
[13:36] <johnt> cjwatson: cool, thanks! im basically just trying to make the security update server bit match the server it is pointed at. as in, when i install the machine the lines in the sources.list dont seem to match the dir structure of the server i am pointing at...
[13:37] <cjwatson> johnt: apt-setup/security_host and apt-setup/security_path are the usual things to tweak
[13:37] <cjwatson> the former defaults to security.ubuntu.com and the latter defaults to /ubuntu
[13:37] <tseliot> pitti: where's the code? In the ubuntu branch in bzr?
[13:38] <tkamppeter> doko, as pitti says that icc-profiles is for optional installation anyway, we could leave it in Multiverse.
[13:38] <doko> pitti, tkamppeter: some of the profiles have a rstriction on modification
[13:38] <johnt> cjwatson: yeah, thats what im working on. just not sure what they should look like by looking at the mirror, if that makes sense. presumably the first one is literally just the name of the mirror with nothing appended?
[13:38] <cjwatson> johnt: literally just the host name, yes
[13:39] <doko> tkamppeter, pitti: is there already other printer stuff in restricted?
[13:39] <cjwatson> johnt: which mirror?
[13:39] <johnt> cjwatson: ok cool, so for the second one i just had "...security_path string /ubuntu" but that doesnt seem to have worked
[13:39] <pitti> doko: not according to grep ^Package: /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_oneiric_restricted_binary-amd64_Packages
[13:39] <tkamppeter> doko, as far as I know, not.
[13:39] <johnt> cjwatson: internal mirror :S
[13:40] <pitti> doko: but as it's not a "real" driver, I agree with you that it's probably better to split it into a free and non-free part, and leave it in multiverse for now
[13:40] <cjwatson> fair enough
[13:41] <johnt> cjwatson: so, is there a way to work out what the path should be by looking at the dir structure on the mirror?
[13:41] <doko> pitti: the reason that debian doesn't have color profiles in main, is that there is hardly any free editor to edit these
[13:42] <cjwatson> johnt: there'll be a dists directory somewhere; use the path for its parent directory
[13:42] <cjwatson> johnt: e.g. if you have http://mirror.example.com/foo/bar/baz/dists/natty/..., then 'd-i apt-setup/security_host string mirror.example.com' and 'd-i apt-setup/security_path string /foo/bar/baz'
[13:43] <doko> tkamppeter, gets ptouch-driver seeded somewhere?
[13:44] <tseliot> pitti: also what do you mean by "WI"?
[13:44] <tkamppeter> doko, not yet. I have opend bug 823545,
[13:44] <pitti> tseliot: "work iem", sorry
[13:45] <pitti> tseliot: there's no code yet, it's a todo item assigned to me
[13:45] <pitti> tseliot: it's blocked on actually having the packages available
[13:45] <doko> tkamppeter, why don't you use the ubuntu-printing group when subscribing to these packages?
[13:45] <tseliot> pitti: ok, so the answer to that question would be "yes" then ;)
[13:45] <pitti> tseliot: thanks, updating
[13:45] <johnt> cjwatson: strange, thats what i had. its basically: host.domain.com/ubuntu/dists/ so i had "security_path string /ubuntu" and the updates seem to work during the install but the security lines in sources.list are all messed up - does that make sense?
[13:51] <tkamppeter> doko, done, ubuntu-printing is now subscribed to the new driver packages.
[13:51] <johnt> cjwatson: any idea what might cause that?
[13:52] <cjwatson> johnt: can I see the exact preseed file (with passwords removed, of course) and the exact resulting sources.list?
[13:53] <cjwatson> paste.ubuntu.com may be helpful
[13:53] <johnt> cjwatson: sure, ill have to run the build again which could take 40 mins...
[13:54] <cjwatson> johnt: you could show me the preseed file before that
[13:54] <johnt> cjwatson: one question before i do that: what is the "d-i apt-setup/services-select multiselect security" line for?
[13:55] <cjwatson> johnt: you shouldn't need that
[13:55] <cjwatson> johnt: seeing as it's the default
[13:55] <slangasek> wendar: aha, I guess I missed that part of the mailing list discussion, ok
[13:56] <johnt> cjwatson: could possibly be the cause of my problem?
[13:56] <cjwatson> johnt: no, it's a no-op
[13:56] <cjwatson> irrelevant to this
[13:56] <johnt> cjwatson: ok 1 sec and ill de-password this preseed for you... :D
[13:58] <johnt> cjwatson: does a trailing / make any difference on that security_path line?
[13:59] <cjwatson> johnt: it would result in a trailing / in the sources.list lines, but that should never matter
[13:59] <cjwatson> johnt: it would help in all this if you could tell me at least roughly *how* the security lines in sources.list are messed up
[13:59] <cjwatson> it's a bit vague so far ...
[14:00] <johnt> cjwatson: ill have to build the machine again to get the exact lines but they dont appear to match the directory structure of the mirror...
[14:05] <johnt> cjwatson: http://paste.ubuntu.com/663429/
[14:07] <cjwatson> johnt: I don't see anything obviously wrong, so let me know when you can show me the resulting sources.list and point out the problemin it
[14:07] <cjwatson> *problem in it
[14:07] <johnt> cjwatson: cool, thanks!
[14:23] <doko> seb128: could you upload poppler to build with jpeg8?
[14:24] <seb128> doko, I can have a look, do we transition to the new version?
[14:25] <seb128> or is that to see if that fixes the openjpeg issue?
[14:27] <envygeeks> Can somebody link a document or explain to me package naming in backports? Is it fine to use the original package name when backporting?
[14:28] <Laney> envygeeks: append ~release1
[14:28] <Laney> https://help.ubuntu.com/community/UbuntuBackports#Source%20Change%20Backports
[14:32] <envygeeks> Laney: Thank you, I guess I missed that >.<
[14:51] <doko> jamespage, about fop, should 0.95 be used, or 1.0?
[14:52] <jamespage> doko: 0.95 - 1.0 is still not build-able  without bundled libraries
[14:52] <doko> thanks
[14:54] <jamespage> np
[15:06] <ricotz> doko, hello, i hope you can have a short look, this happens on natty i386 (build for amd64 works fine), could this be a compiler issue? http://paste.debian.net/plain/125903
[15:13] <mvo> hm, so cups in maverick depends on cups-ppdc that is in universe? that does not look right. it got added via a maverick-proposed upload
[15:54] <johnt> cjwatson: hey, still there?
[15:55]  * infinity looks at all the bundled libs in likewise-open and wonders how this got into main like this...
[15:58] <slangasek> huh, it's in main?
[16:00] <directhex> so..... i guess feature freeze is today?
[16:00] <Laney> 21:00
[16:01] <directhex> we get a dinstall run before then, surely
[16:01] <infinity> slangasek: It looks like it's in main to me...
[16:01] <slangasek> infinity: what a strange thing :)
[16:01] <Laney> spank mhy a lot and one will fall out
[16:01] <cjwatson> johnt: yes
[16:02] <directhex> Laney, i already owe him beer!
[16:02] <johnt> cjwatson: i have the sources.list for you...
[16:02] <cjwatson> johnt: shoot
[16:02] <Laney> upgrade that to rum and all will be well
[16:03] <Laney> directhex: alternatively, file the request manually; I doubt anyone will get round to it before it dinstalls
[16:03] <matttbe> Hello,
[16:03] <matttbe> I know I'm sorry to annoy you with that... Sorry to resend this request and sorry to be a bit late but I'm still looking for a sponsor in order to upload 3 packages to universe repositories before the feature freeze.3 bzr branches have been created. 'bzr merge-upstream' has been used to commit these new revisions and they should be ready to be uploaded. bug #823513 ; bug #823514 ; bug #823566
[16:03] <Laney> to the climbing centre!
[16:03] <matttbe> I hope it's not too late (21:00 UTC or something else? not 16:00 or 18:00 UTC?) or maybe should I already send a request for an exception to 'FeatureFreeze'. But sorry if we still have some time.
[16:04] <Laney> matttbe: how long have you been maintaining these packages for now? Have you considered applying for upload rights for them?
[16:05] <johnt> cjwatson: http://paste.ubuntu.com/663503/
[16:05] <matttbe> Laney: since Karmic release. Yes, I should do that...
[16:05] <matttbe> (I forgot to do that...)
[16:05] <cjwatson> johnt: so what should the URL be instead of http://lcsiupd.domain.com/ubuntu ?
[16:06] <johnt> cjwatson: thats correct except "domain" is our domain name...
[16:07] <cjwatson> johnt: I can't help you if you can't tell me what's wrong
[16:07] <cjwatson> I can see that apt-get is telling you that some of the URLs don't work, but since I don't have access to your mirror I have no idea what they should be
[16:07] <johnt> cjwatson: the apt-get update error is in that paste at the top - can you see it?
[16:07] <cjwatson> the installer is doing what you told it to do in your preseed file
[16:08] <johnt> cjwatson: 1 sec... phone... :|
[16:08] <cjwatson> yes, I can see the apt-get errors, but I cannot tell you what the fix should be since I don't have access to your mirror
[16:08] <cjwatson> if you could *be precise* about what the offending sources.list lines should look like, then I can help; otherwise I cannot
[16:09] <infinity> If I had to guess, I'd say the fix is "mirror sources"...
[16:09] <juliank> Everything looks totally correct as far as I can see on the client side.
[16:09] <cjwatson> sure, that's possible
[16:14] <cjwatson> does anyone who is not in techboard or ubuntu-release have a bug task they'd like to nominate for a stable release?
[16:14] <cjwatson> right now you can just do it; I want to make a change to the stable release ownership in LP and would like to make sure that doing so does not break it
[16:14] <cjwatson> anyone> I mean somebody in ubuntu-core-dev
[16:15] <geser> can't MOTU after this change open task for SRU anymore?
[16:17] <cjwatson> you ought to be able to, but I am more interested in the test for ubuntu-core-dev
[16:17] <cjwatson> because right now the series owner is ubuntu-core-dev and I want to change it to ubuntu-release
[16:17] <cjwatson> I'm not intending to break MOTU, but it is not relevant to the test I am trying to perform
[16:17] <geser> ok
[16:18] <geser> I asked because you asked for a core-dev
[16:18] <slangasek> jdstrand: you know a lot about thinkfan, right?
[16:22] <slangasek> jdstrand: in oneiric, setting 'level disengaged' doesn't take... even when thinkfan isn't running, something resets me to 'auto' after a few seconds :P
[16:23] <slangasek> hmm... in fact, it seems to reset to auto right when /proc/acpi/ibm/thermal reaches 90
[16:24] <slangasek> which is great, since the whole reason I'm setting it to 'disengaged' is because the other levels fail to bring the fan up to full speed when the system is overheating :P
[16:34] <micahg> slangasek: he's on vacation :)
[16:35] <slangasek> micahg: answers to the problem gratefully accepted from people who are not :)
[16:36] <victorp> akgraner, hi
[16:41] <akgraner> victorp, hi!
[16:43] <doko> seb128, TheMuso: ibus-pinyin is dep-wait on a new ibus, how safe would be the sync?
[16:44] <cjwatson> I have now changed the driver for all stable releases to ubuntu-release, and verified that this does not regress the ability of a core-dev to target tasks to a stable release
[16:45] <seb128> doko, I've no clue about ibus but we have a diff so it's a merge in any case
[16:45] <seb128> the new version is in debian unstable for some weeks without rc bugs
[16:45] <seb128> so I guess it should be fine
[16:46] <tkamppeter> mterry, doko: I have split the icc-profiles package into free and non-free now, see bug 822587.
[16:57] <doko> barry, you did touch ibus last ;p
[16:57] <barry> doko: probably
[16:58] <johnt> cjwatson: hey, sorry about that, people keep calling me and trying to make me do work :(
[16:58] <johnt> cjwatson: would it help if i could show you the dir structure of the mirror?
[16:59] <cjwatson> sure
[16:59] <cjwatson> but I think infinity is likely correct
[16:59] <cjwatson> your mirror doesn't appear to have source code on it
[16:59] <johnt> im sorry, i dont understand - does that mean that the mirror was set up incorrectly?
[17:00] <cjwatson> arguably incorrectly
[17:00] <cjwatson> right now we don't support binary-only mirrors particularly gracefully (none of our standard mirrors are binary-only), although something like   d-i preseed/late_command sed -i 's/^deb-src/#deb-src/' /target/etc/apt/sources.list   would work around it
[17:00] <cjwatson> it might well be easier to get the mirror fixed though
[17:09] <sladen> 2100 UTC eh
[17:11] <johnt> cjwatson: http://paste.ubuntu.com/663554/
[17:11] <johnt> cjwatson: i didnt fill it all in - just enought so that you can see the structure...
[17:11] <directhex> Laney, filed. i even remembered the changelog.
[17:12] <cjwatson> johnt: right, so your mirror has no source code on it
[17:12] <cjwatson> johnt: either get the mirror admin to mirror source packages too, or use the preseed/late_command workaround I suggested above
[17:12] <doko> pitti, barry: ibus-pinyin is dep-wait on a new ibus, please merge
[17:12] <johnt> cjwatson: yeah i noticed that
[17:14] <johnt> cjwatson: so, its just the fact that the mirror is binary only thats causing the problem?
[17:14] <cjwatson> looks like it
[17:14] <cjwatson> all your errors are on Sources.gz files
[17:14] <johnt> cjwatson: thats fantastic :D thanks so much for all your help!
[17:15] <johnt> cjwatson: time to send a strongly worded email to the mirror admin :P
[17:18] <tkamppeter> pitti, hi
[17:18] <tkamppeter> pitti, can you pass icc-profiles-free through NEW?
[17:18] <tkamppeter> pitti, bug 822587
[17:23] <slangasek> anyone around that understands alsa .conf files in all their horror? :)
[17:28] <tseliot> bdmurray: can you renew my membership of ubuntu-bugcontrol please? (I'm albertomilone on launchpad)
[17:30] <bdmurray> tseliot: as a developer your direct membership is unnecessary
[17:31] <tseliot> bdmurray: oh, I didn't know. Thanks
[17:32] <kees> hi, can an archive admin please sync apparmor from Debian for me?
[17:32] <bdmurray> tseliot: oh by the way I think I've noticed some weird blank debconf prompts when installing nvidia-common
[17:34] <tseliot> bdmurray: blank? How did it happen?
[17:39] <bdmurray> tseliot: it was a wee bit ago but I seem to recall running update-manager and briefly seeing a debconf window title that would disappear right away
[17:40] <bdmurray> tseliot: I thought I'd tracked it down to /etc/kernel.d/postinst.d/nvidia-common
[17:40] <tseliot> bdmurray: ok but nothing else (as in "bad") happened, right?
[17:40] <bdmurray> tseliot: right it was just a strange popup that disappeared right away
[17:41] <cjwatson> kees: could you requestsync it?
[17:41] <cjwatson> it has a bunch of Ubuntu changes
[17:42] <cjwatson> not saying I won't do it, it's just easier with the tools ...
[17:43] <kees> cjwatson: yup already done. let me figure out wherr LP put the bug number
[17:44] <tseliot> bdmurray: ok, I'll have a look at the package and see what's going on. Thanks for reporting
[17:46] <kees> lp: #824681
[17:46] <cjwatson> kees: oh, if it's done, I'll just do a queue run
[17:46] <kees> cjwatson: cool, thanks
[18:02] <cjwatson> sabdfl: available for TB?
[18:48] <blueyed> Can somebody hint me at a command line tool which ubuntu uses to setup the system wide proxy? (I want to setup/remove proxies from a guessnet-enhanced interfaces file), and would like to avoid writing an own script for handling *_proxy in /etc/environment (+ the gnome config).
[18:49] <dobey> how does one override the "python setup.py build" bit, when using dh_python2 w/cdbs?
[18:49] <dobey> just override binary/foo::?
[18:54] <kees> @pilot in
[18:55] <dobey> hi kees
[18:56] <dobey> barry: surely you know the answer to my question ^^ :)
[18:58] <broder> dobey: you probably want something like override_dh_auto_build:\n\tdh_auto_build -- --my-extra-params
[18:58] <broder> oh, cdbs
[18:59] <barry> cdbs hurts my brain
[18:59] <barry> sorry, not you cdbs :)
[18:59] <kees> heya dobey
[18:59] <broder> dobey: what do you want to change it to?
[18:59] <dobey> yeah, cdbs. i need to work around a bug in distutils extra, by runnin python setup.py build using xvfb-run :(
[18:59] <broder> you can set DEB_PYTHON_BUILD_ARGS_my-package to pass additional args
[19:00] <dobey> i don't need to change the args, i need to change the "python" command
[19:01] <broder> dobey: that doesn't look possible without digging into cdbs in ways that seem pretty fragile
[19:04] <dobey> :(
[19:07] <slangasek> step 1) stop using cdbs
[19:07] <slangasek> step 2) profit
[19:07] <dobey> stop using python :)
[19:08] <slangasek> nah, python is great.  cdbs is not
[19:08] <dobey> ok, so how would i change the "python" command itself, without using cdbs?
[19:08] <seb128> jelmer, james_w, others: how do I tell bzr-builddeb to stop commiting using the changelog diff as a commit message without letting me edit it?
[19:09] <dobey> seb128: that's odd. it's always let me edit the message in $EDITOR
[19:10] <seb128> it was doing that until I upgraded yesterday for me
[19:10] <dobey> seb128: new bzr?
[19:10] <seb128> well that's specific to packaging vcs-es
[19:10] <seb128> new bzr-builddeb
[19:10] <dobey> weird
[19:10] <seb128> it used to open $EDITOR with the diff ready to edit
[19:10] <slangasek> dobey: if you were using dh, it would be override_dh_auto_build:\n\txvfb-run python setup.py --install-layout=deb + $options
[19:10] <seb128> now it seems to think it doesn't need to ask for edit
[19:10] <slangasek> dobey: (more or less - season to taste)
[19:11] <dobey> ugh :)
[19:12]  * dobey sticks with being a pythanthrope
[19:12] <seb128> grrrr bzr-builddeb
[19:12] <dobey> or pythonthrope
[19:13] <slangasek> dobey: <shrug> sometimes you have to override the defaults of the debian/rules build system... I don't think that's python's fault :)
[19:13] <dobey> slangasek: no, but cdbs generally makes this somewhat nice. it just happens to be less nice with python
[19:14] <dobey> slangasek: and i also already do not like python :)
[19:14] <slangasek> no, cdbs doesn't make anything nice
[19:14] <slangasek> cdbs is only nice when you *don't* have to override things
[19:14] <dobey> DEB_CONFIGURE_SCRIPT = $(CURDIR)/$(DEB_SRCDIR)/autogen.sh
[19:14] <dobey> that is pretty nice
[19:14] <infinity> cdbs is the past.  dh7+ is the future.
[19:14] <dobey> don't have to copy all the default --prefix=/ --blah=/foo crap
[19:14]  * infinity passes the Kool-Aid.
[19:15] <slangasek> except for the part where all the variable names are undiscoverable :)
[19:15] <dobey> all i want to change is the python being run, not the arguments
[19:15] <broder> dobey: don't you just use dh_autoreconf for that?
[19:15] <dobey> eh, grep DEB_ works well :)
[19:15] <dobey> broder: no
[19:15] <dobey> autoreconf != autogen.sh
[19:15] <juliank> dobey: You should use dh-autoreconf to autogen.sh
[19:15] <juliank> or cleanup manually.
[19:16] <dobey> again, autoreconf != autogen.sh
[19:16] <slangasek> who's to say autogen.sh has anything to do with autotools :)
[19:17] <slangasek> OTOH, if it *is* autotools, running autoreconf is almost always more reliable than an upstream-provided autogen.sh
[19:17] <juliank> If it changes something and you do not know what, you can use dh-autoreconf.
[19:17] <dobey> almost always less reliable, rather :)
[19:17] <slangasek> er, no
[19:17] <juliank> Whether you use autotools or something else is not important
[19:17] <juliank> dh-autoreconf can run anything you want it to run.
[19:17] <dobey> does dh_autoreconf handle all the third party extensions stuff on top of autotools now?
[19:17] <dobey> i doubt it.
[19:18] <slangasek> I don't know what you mean by "third party extensions"
[19:18] <juliank> dobey: You can run the autogen.sh script using dh_autoreconf ./autogen.sh
[19:18] <dobey> i mean gnome-autogen.sh with intltool and other such stuff, which are run through autogen.sh
[19:19] <dobey> juliank: and that uses all the default arguments without me having to pass them again in rules?
[19:19] <juliank> You just should suppress running configure in autogen.sh, otherwise things may get strange.
[19:19] <slangasek> yeah, doesn't look like the intltool bits are supported by autoreconf, unfortunately
[19:19] <dobey> and in another 6-12 months, dh will be the past, and something else will be the future. so whatever :)
[19:19] <dobey> i'll stick with what works
[19:19] <slangasek> no
[19:19] <infinity> dobey: debhelper seems unlikely to be the past. :P
[19:20] <juliank> dobey: You're thing does not work. It does not clean up afterwards, as you're required to.
[19:20] <dobey> juliank: what are you talking about?
[19:20] <dobey> *my* things works perfectly.
[19:21] <juliank> dobey: Changes to upstream files, the generated Makefile.in, etc.
[19:21] <juliank> They need to be removed in clean
[19:21] <juliank> That's why I wrote dh-autoreconf.
[19:21] <dobey> juliank: there is no Makefile.in; this is from straight vcs checkout.
[19:21] <dobey> if it was from a tarball, i wouldn't be running autogen.sh
[19:21] <dobey> i would be running configure
[19:22] <dobey> and preferrably, not patching the build system
[19:22] <slangasek> dobey: you can continue to use cdbs if you wish, but it enjoys near universal disdain, and you were asking here how to do something cdbs isn't letting you do; the consensus answer is "use dh"
[19:22] <juliank> dobey: You still have to remove them anyway, otherwise they get in your .debian.*/.diff.gz
[19:23] <seb128> slangasek, stop trolling cdbs ;-)
[19:23] <dobey> slangasek: right. and dh doesn't let me do *exactly* what i want either
[19:24] <dobey> juliank: if there is no .orig.tar.gz, they don't end up in the .diff.gz
[19:24] <slangasek> seb128: is it trolling?  I thought you guys had finally gotten all the gnomey package bits ported to dh :)
[19:24] <juliank> dobey: Then they end up in the tarball.
[19:24] <dobey> juliank: yes. which is where they belong
[19:24] <seb128> slangasek, hehe, I don't think we ported a single one ;-)
[19:24] <chrisccoulson> i like cdbs!
[19:24] <seb128> see!
[19:25] <juliank> dobey: No, then you wouldn't do it during build, but before.
[19:25] <slangasek> seb128: right, I thought they were "ported" to dh by moving them to pkg-mangler? :)
[19:25] <dobey> juliank: i don't make nightly builds by making tarballs all the time, and then using them as orig.tar.gz
[19:26] <dobey> anyway
[19:26] <juliank> If you run autoreconf or similar during the build, and then recreate the source package later on, the source package might be different, as the auto* on the host changed.
[19:26] <dobey> juliank: and i don't much care. because they are unstable nightlies for a reason :)
[19:27] <seb128> slangasek, no trolling there, right? ;-) Though I would admit with dh-translations and gnome-pkg-tools having a --with gnome now I think dh is somewhat usuable ;-)
[19:27] <juliank> dobey: OK. But it's nothing that should be done in the official archive(s)
[19:28] <juliank> that is, in official Ubuntu or Debian packages.
[19:28] <james_w> seb128, bug 812749
[19:29] <seb128> james_w, thanks
[19:29] <ScottK> slangasek: Maybe it was KDE you were thinking of.  ~all the KDE packages use DH now.
[19:29] <seb128> I downgraded for now so I can commit my work
[19:29] <slangasek> ScottK: nah, I remembered seeing the dh-translations work related to getting dh usable for GNOME packages
[19:29] <ajmitch> ScottK: a good reason for me to switch to kde then
[19:29] <dobey> juliank: agreed. and for there i prefer to avoid touching build system at all, and keeping pure upstream source as close as possible
[19:30] <ScottK> As if there were a shortage ....
[19:30] <seb128> slangasek, right, we got dh-translations and a --with gnome in gnome-pkg-tools
[19:30] <seb128> slangasek, so technically we can use dh ;-)
[19:30] <infinity> ScottK: I thought the usual argument was just that people like blue.
[19:30] <slangasek> seb128: but you prefer to stick with cdbs?  I thought the tooling was the only blocker, and that there was a consensus for the GNOME team to move to dh once that was done
[19:31] <seb128> slangasek, no, cdbs just works fine enough that I can't be bothered converting sources ;-)
[19:32] <slangasek> ok, sure
[19:32] <seb128> slangasek, we tend to do new sources using dh though
[19:32]  * slangasek nods
[19:35] <dobey> also, requiring man pages for graphical programs, feels a bit like requiring graphical help for 'less' with screenshots and everything.
[19:36] <slangasek> dobey: "requiring" :)
[19:36] <slangasek> it's an unenforced bit of policy
[19:36] <dobey> right
[19:36] <dobey> but seeing the lint warning is annoying
[19:39]  * dobey wonders why dh on oneiric doesn't just default to using dh_python2 instead of pysupport.
[19:40] <slangasek> I think the remaining reason is that it's an incompatible change in debhelper behavior, so requires a new debhelper compat level
[19:42] <dobey> lovely. :-/
[19:42] <dobey> and now gpg suddenly won't accept my passphrase, and the seahorse/keyring gui agent integration bits aren't working. :(
[19:43] <dobey> guess i'll have to reboot and see if it works then
[19:43] <bdmurray> kees: hello mr patch pilot
[19:44] <bdmurray> kees: could you review https://code.launchpad.net/~brian-murray/ubuntu/oneiric/apport/unreportable-pkg-conflict/+merge/71264
[19:48] <ScottK> bdmurray: If you have a moment, I'd like to discuss Bug 702283 being "Wishlist".
[19:49] <bdmurray> ScottK: Why don't you just change it and I promise not to get in a reversion war with you
[19:50] <ScottK> bdmurray: Works for me.  Thanks.
[19:52] <KaiserClaudius> Have the daily live images moved? Wanted to get a zsync refresh for testing today, but on the usual location ( http://cdimages.ubuntu.com/daily-live/ ) there suddenly seem to be only images for PowerPC o.O
[19:56] <charlie-tca> KaiserClaudius: they are broken
[19:57] <charlie-tca> maybe tomorrow we will have new images
[19:57] <KaiserClaudius> ah ok, thanks :)
[20:07] <kees> bdmurray: sure, one sec. working on cairo-dock atm
[20:15] <dobey> kees: could you reivew https://bugs.launchpad.net/ubuntu/+bug/817133 for me? we'll need an MIR for it later, but would like to get it in universe before FF if possible. thanks :)
[20:15] <broder> ScottK: Wait, I'm confused. In the usb-creator case (as opposed to the "dd the iso onto the USB drive" case), I thought all you needed is a /efi/boot/bootx64.efi file, which the natty CD at least has
[20:15] <broder> (i.e. you don't need any special partition table mangling or anything like that)
[20:16] <ScottK> Dunno.
[20:16] <ScottK> I don't have a mac, but if you can't get a bootable image on the stick, I think that's not wishlist
[20:17] <kees> dobey: sure
[20:17] <broder> ScottK: I'll take a look at it later, but I believe the actual scope of that bug is more narrow than the description suggests (i.e. only affects older Macs, and not non-Mac UEFI machines)
[20:18] <kees> dobey: oh, heh, this needs MIR, deNEW also? not sure that can happen in the next hour
[20:19] <ScottK> broder: We were unable to test Kubuntu amd64+mac due to it not working in Alpha3.  If that bug doesn't cover that, then the dupe needs to be unduped.
[20:19] <dobey> kees: well, MIR doesn't need to happen in the hour. NEWed to universe would be a nice start :)
[20:23] <kees> dobey: I can review and sponsor, deNEW will have to be an archive admin. I'll get started; have to wait for cairo-dock to build in archive anyway :)
[20:25] <dobey> kees: ah ok. i thought you were an archive admin too. but that is fine, as long as it's approved/uploaded i'm happy :)
[20:26] <kees> oop, being forced to lunch. will continue shift when I'm back
[20:26] <kees> @pilot out
[20:26] <kees> dobey: since nothing depends on it yet, it'll be an easy FFe. I'll keep looking at it
[20:26] <micahg_> kees: dobey: deNEWing can happen after FF as long as it's uploaded
[20:28] <dobey> micahg: right. i'm just trying to avoid the FFe :)
[20:41] <slangasek> ScottK: hey, can I multiarch qt4-x11? :)
[20:42] <ScottK> Can you finish in 19 minutes?
[20:42] <slangasek> it'll be fun to try
[20:42] <ScottK> For the next 18 minutes, I've got no opinion on the matter.
[20:42] <slangasek> ok cool
[20:45] <slangasek> bdmurray: "Refusing bug filing if the conflicting package isn't an Ubuntu package" - <hug>
[20:46] <slangasek> that should take out about a quarter of the ongoing plymouth bug reports...
[20:46] <bdmurray> slangasek: really?  I queried the local ones here and didn't find many
[20:47] <slangasek> bdmurray: I've been whacking them with a hammer each time
[20:47] <bdmurray> slangasek: oh right I'm only looking at the open bugs ;-)
[20:47] <slangasek> this is the "broken Malaysian Ubuntu derivative with no English language contact link on their website" case
[20:51] <ScottK> It would be nice to have a sekrit developer override for the "I know, but it'd be really nice to throw this a the apport retracers" case.
[20:53] <ajmitch> APPORT_ME_HARDER environment variable?
[21:01] <ScottK> Nice.
[21:02] <Laney> :-)
[21:04] <iulian> Enjoy and don't break things. :)
[21:05] <slangasek> ScottK: "Can I finish in 19 minutes" - whoops, timestamp says it was 20, I didn't look closely enough at the clock before dputting ;P
[21:05] <ScottK> I'll live as long as you clean up any resulting messes.
[21:05] <slangasek> yep
[21:05] <Laney> OMG freeze break
[21:07] <barry> pitti: any chance you're still around?
[21:14] <micahg> barry: summit dinner unless he's back from it
[21:14] <barry> micahg: ah, okay.  i have a merge if ibus i'm mostly looking for a review of (if my local build succeeds)
[21:14] <dobey> kees: thanks for the sponsoring!
[21:15] <seb128> barry, kees is patch pilot maybe he can sponsor it for you ;-)
[21:15] <dobey> ok, am off now. cheers all!
[21:15] <doko> barry: just point me to it, if your test build succeeds
[21:15] <barry> seb128: don't need a sponsor, but maybe he can review it.  i just need another pair of eyes since i'm not very familiar with the code
[21:16] <seb128> oh ok
[21:16] <barry> doko: fab!  will ping you when it completes
[21:16] <seb128> barry, I don't think pitti is familiar with the ibus code either
[21:16] <seb128> barry, just upload, we will deal with issues ;-)
[21:16] <seb128> barry, oh, doko said he would look at it, great
[21:16] <barry> seb128: he did the last merge :)
[21:17] <seb128> yeah because the new version was needed and somebody needed to do it ;-)
[21:30] <barry> seb128: ;)
[21:30] <barry> doko: lp:~barry/ubuntu/oneiric/ibus/sid-merge
[21:30] <barry> doko: thanks!
[21:32] <jelmer> seb128: that's bug 812749
[21:33] <seb128> jelmer, thanks, james_w pointed it to me before
[21:33] <jelmer> ah, sorry
[21:57] <barry> doko: i have to run out to pick up guido, who's in town for a visit.  if i see your feedback when i get back, cool, otherwise, i'll just upload it and we'll deal with any fallout after ff.  cheers!
[21:59] <directhex> soooooooo, time for another requestsync!
[22:20] <tkamppeter> mterry, doko: icc-profiles source package is split now into icc-profiles and icc-profiles-free. Latter needs to be NEWed, see bug 822587.
[22:32] <barry> doko: uploaded
[22:46] <mterry> tkamppeter, ok, will look
[22:56] <mterry> eh, i'll wait until it's through new
[23:39] <matttbe> kees: thanks for the sponsoring! ;) (cairo-dock packages)