[00:07] <wendar> AlanBell: you rock, thanks! (for the tarball)
[01:05] <broder> stgraber: haha. way to grab bug #1e6
[01:05] <broder> no, not that one :-P
[01:05] <ajmitch> silly bot
[01:06] <stgraber> :)
[06:58] <Rhonda> hah, again self-fixed problem, love those. :)
[11:24] <wookey_> I have an ubuntu package which uses dh-translations and thus calls dh -Spython_distutils --with python2,translations
[11:24] <wookey_> dh-translations does not exist in debian
[11:25] <wookey_> the rules file can easily be fixed up with dpkg-vendor
[11:25] <wookey_> but I see no clean way to deal with the difference in build-deps.
[11:25] <wookey_> Do lots of ubuntu packages have a delta adding dh-translations as a build-dep?
[11:26] <wookey_> Is there a better way to deal with this? (package is usb-creator)
[11:29] <wookey_> Also there are xml .ui files for gtk and kde. where it would be useful to insert either Ubuntu or Debian as approporiate. Is there a neat way to do this (nicer than sedding ui.in files in rules)?
[12:07] <geser> wookey_: I guess you need a source package for Debian and one for Ubuntu then
[12:08] <geser> but if you manage this package in a VCS you could create an Ubuntu branch with all the needed Ubuntu delta (labels, build-deps, etc.) and rebase it on every new package revision
[12:15] <Daviey> wookey_: conditional symlink based on lsb distro?
[12:16] <Laney> you can have the build system substitute in based on a configure flag
[12:16] <Laney> but I don't know of a solution for the build-deps.
[12:43] <Adri2000> isn't it possible to have a template control file debian/control.in which regenerates debian/control at build?
[12:46] <azeem_> it is discouraged I believe
[12:48] <Laney> I don't see how that could work for build-deps
[12:57] <Adri2000> according to http://raphaelhertzog.com/2010/09/27/different-dependencies-between-debian-and-ubuntu-but-common-source-package/#comment-3779 it should work, even though that's not really clean I admit
[13:01] <Laney> clean isn't run until after b-ds are installed
[13:01] <Laney> have a look at a build log to verify
[13:05] <highvoltage> moo
[13:05]  * Laney zaps highvoltage 
[13:06] <highvoltage> *BZZZT*
[13:10] <geser> Laney: don't produce a short circuit when playing with highvoltage
[13:28]  * bregma sips his coffee
[18:32] <hyperair> Zhenech: ping.
[18:32] <hyperair> Zhenech: why isn't libappindicator in debian? =\
[18:34] <Zhenech> hyperair, because you didnt package it </defaultanswer>
[18:34] <Resistance> lol...
[18:34] <hyperair> Zhenech: and the reason for that is because pkg-ayatana insists on using bzr.. ¬_¬"
[18:34] <hyperair> Zhenech: i thought you were maintaining the indicator stack in debian though. isn't it pretty useless without appindicator as well?
[18:36] <Zhenech> no, works w/o quite good
[18:36] <Zhenech> and yes, bzr sucks
[18:36] <Zhenech> but makes "stealing" from ubunto so mucheasier
[18:46] <hyperair> hm
[18:46] <hyperair> how so?
[18:46] <hyperair> you would have to merge from ubuntu into debian, and then back again, wouldn't you?
[18:46] <hyperair> doesn't it get really weird there?
[18:49] <geser> or upload it as 1.2.3-0debian1 :)
[18:52] <Zhenech> hyperair, i always wait till ubuntu hass foo-0ubuntu1 and merge that
[18:53] <hyperair> hmmmm.
[18:53] <hyperair> i see
[18:53] <Zhenech> super easy
[21:46] <bkerensa> micahg: https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate <-- apparently needs some love
[21:48] <tumbleweed> bkerensa: we'd love to get to thepoint where we can remove those pages and just point people at the packaging guide
[21:48] <bkerensa> :D
[21:48] <micahg> bkerensa: well, we have http://developer.ubuntu.com/packaging/html/udd-merging.html#merging-a-new-upstream-version
[21:49] <tumbleweed> which means either cover non_UDD workflows in the packaging-guide or get everyone usin gUDD (which requires it to work :P )
[21:49] <ajmitch> it works, just not in all cases :)
[21:50] <tumbleweed> fair enough
[21:50] <tumbleweed> and I doubt we could call the traditional way of doing things "working" when there's a multi-k-line diff in a 1.0 source package
[21:52]  * ajmitch would like for a good solution to bzr+quilt that works for every package, but that requires some work
[21:52] <tumbleweed> it sounds like we know what it might be, but nobody is putting the work in
[21:54] <ajmitch> sounds like a great opportunity for someone who likes pain :)
[21:55] <bkerensa> ;p
[21:55]  * tumbleweed bets the git people get there first. there's certainly way more experementation on that side of the fence
[21:56] <ajmitch> then we can move all ubuntu branches to git?
[21:56] <tumbleweed> launchpad has to support it first :)
[21:56] <ajmitch> mere details
[21:56] <tumbleweed> not that I'm a bzr hater. But I quite like git too
[21:57] <tumbleweed> and it appears to have won
[21:57] <Laney> there was a "talk to" item about the .pc ignoring stopgap
[21:57] <Laney> that certainly seems more likely than making looms work
[21:57] <ajmitch> Laney: right, I can't recall if the importer was going to unapply patches
[21:57] <tumbleweed> definitly sounds like there are stopgaps that'll make things a lot better
[21:57] <ajmitch> looms seem like a nice-to-have
[21:57] <tumbleweed> ajmitch: I think we decided not to do that, it would be fairly insane
[21:57] <ajmitch> right
[21:58] <Laney> patches would be applied, and that's what you want really
[21:58] <tumbleweed> but rather to get as little of .pc in the branch as possible
[21:58] <Laney> but you can construct .pc on checkout
[21:58] <Laney> so it doesn't need to hit the vcs
[21:58] <tumbleweed> oh, right, that
[21:58] <ajmitch> http://summit.ubuntu.com/uds-q/meeting/20342/foundations-q-udd/ wasn't entirely clear on which way was chosen & my memory is foggy :)
[21:58] <ajmitch> aha
[21:59]  * tumbleweed wasn't a great note-taker this UDS :/
[22:02] <ajmitch> tumbleweed: I'm sure you did a better job than I did :)
[22:04]  * tumbleweed also should have raised the debian stuff with debian-derivatives before the sessions, calling for input
[22:04] <highvoltage> I wish I'd taken more notes but I was completely information-overloaded
[22:04] <tumbleweed> we're bad DDs
[22:05] <micahg> heh
[22:05] <tumbleweed> highvoltage: there were some sessions where I volunteered to take notes and then found myself staring into space or diving into arguments and losing track of the notes
[22:05] <ajmitch> good thing you grabbed the audio then
[22:06] <highvoltage> well, there were /some/ sessions where you couldn't be blamed for staring into space :)
[22:06] <tumbleweed> ah, btw, to get things to show up on status.ubuntu.com, all you need to do is mark the session as approved for quantal
[22:06] <ajmitch> oh good
[22:06]  * tumbleweed must go back and check that all his sessions are...
[22:07] <ajmitch> 15% done already
[22:07] <tumbleweed> not bad
[22:07]  * ajmitch is 0% done, blame the ubuflu :)
[22:07]  * tumbleweed is just getting over that
[22:08] <Resistance> what's the methodology of enabling multiverse and universe inside a chroot, would that be adding `multiverse universe` to the apt sources.list lines in the chroots?
[22:09] <tumbleweed> yes
[22:09] <Resistance> indeed, just wanted to confirm
[22:11] <broder> tumbleweed: so should i just set the state on my blueprint to approved?
[22:11] <broder> the...definition state, i guess?
[22:11] <tumbleweed> broder: no, set a "series goal"
[22:12] <broder> aha
[22:12] <tumbleweed> at least that worked for the debian healthcheck fo rme
[22:16]  * Laney wibbles
[22:16] <Laney> EVAN BRODER
[22:16] <Laney> DO WE NEED TO UPDATE THE BACKPORTS DOCS TO MENTION THAT WE UPLOAD OURSELVES NOW
[22:16] <Laney> ??????????????????????????????????????????????
[22:16] <Laney> also, hello!
[22:17] <bkerensa> >.<
[22:17]  * ajmitch takes Laney's shift & capslock keys away
[22:18] <broder> MR LANEY HELLO STOP
[22:18] <ajmitch> Laney: I want to be a backporter pls show me how
[22:18]  * Resistance raises an eyebrow
[22:18] <broder> haha
[22:18] <Resistance> oh...
[22:19] <Resistance> for a minute i thought there was a spammer in here
[22:19] <ajmitch> there was
[22:19] <Laney> i can spam if you want!
[22:19]  * Resistance has autonotify scripts for multiple full-caps lines
[22:19] <Resistance> Laney:  UNDER NO CIRCUMSTANCES
[22:19] <Laney> you want a ghc upload yes yes? then i get to spam you with uploads
[22:19]  * tumbleweed disables capslock. it serves NO PURPOSE
[22:19]  * Laney has it as compose
[22:20] <Laney> there's something satisfying about holding down shift
[22:20]  * Resistance lights his capslock key on fire
[22:20] <ajmitch> Laney: oh we're so looking forward to another ghc transition
[22:20] <broder> HELLO SIR I FROM SUDAN AND MY RICH UNCLE HAS RECENTLY DIED LEAVING ME WITH 6 GAJILLION DOLLARS PLEASE PROVIDE ME WITH YOUR BANK ACCOUNT NUMBER AND I WILL TRANSFER MONEY TO YOU
[22:20] <broder> Laney: docs should probably be updated, but i'm holding off on doing so until i get a tool for AAs to use to verify things in-queue
[22:20] <Resistance> broder:  now that is spam, but i got that three hundred times yesterday...
[22:22] <Laney> ok then
[22:23] <Laney> would you consider making backportpackage not remove the temporary directory if dput errors out?
[22:23]  * micahg was about to ask what the preferred way to upload a backport is now :)
[22:23]  * Laney had to download the widelands >100 meg orig a few times due to various -u fails
[22:23] <ajmitch> ouch
[22:23] <tumbleweed> Laney: seems fair
[22:23] <micahg> Laney: use backportpackage with the .dsc :)
[22:23] <ajmitch> micahg: my preferred way is to ping Laney
[22:24] <micahg> ajmitch: I'm a backporter :)
[22:24] <ajmitch> I'm not that special
[22:24] <Resistance> and micahg and broder are my contacts for backport questions :P
[22:24] <Laney> yeah, but it has this handly ability to download the package for me
[22:24] <Laney> -w . works too I suppose
[22:24] <Laney> want to process python-leveldb and see how you get on with uploading it?
[22:24] <micahg> Laney: that's good the first time around :)
[22:25] <Laney> i.e. if backportpackage does what you want
[22:25] <micahg> Laney: was about to, yes, just waiting for i386 to build in quadrispro's PPA
[22:25] <Laney> cool
[22:26]  * micahg likes the new bug in changelog feature
[22:26] <micahg> helps with the audit trail
[22:27]  * ajmitch sees there's only one admin of the backporters team that's seen around here regularly
[22:27] <bkerensa> micahg: any thoughts on this http://paste.ubuntu.com/991459/
[22:27] <Laney> we call him The Boss
[22:28] <micahg> bkerensa: a bug in setup.y?
[22:28] <micahg> *setup.py
[22:29] <bkerensa> it seems to be defined though
[22:30] <micahg> bkerensa: no idea, maybe someone more versed in python can help
[22:30]  * micahg wonders if the other 2 people in the backporters team should be removed
[22:30] <micahg> oh, nm, they're MOTUs still :)
[22:31] <Resistance> lol
[22:31] <micahg> well, we don't want non-MOTUs/core-devs doing backports
[22:31] <tumbleweed> I thought that wasn't possible?
[22:32] <micahg> what's not possible
[22:32] <ajmitch> micahg: there are a few people pending as backporters, what's the process for helping out?
[22:32] <tumbleweed> non-MOTU / core-devs doing backports
[22:32] <Laney> triage some and get scott to review your work
[22:33] <micahg> tumbleweed: yeah, was worried about lapsed upload rights and what not
[22:43] <eridu> hey motus, I'm watching a critical security bug for the pidgin-otr package -- I'm not sure what the protocol here is, but there's a debdiff on the bug report and an upload about to go into debian -- how could I help the fix get into Ubuntu?
[22:43] <eridu> lp bug is https://bugs.launchpad.net/ubuntu/+source/pidgin-otr/+bug/1000363
[22:43] <kees> eridu: folks in #ubuntu-hardened should be able to guide you
[22:43] <eridu> kees: thanks!
[22:44] <jtaylor> eridu: looks like its already taken care of, its now in the hand of the security sponsors
[22:44] <eridu> oh, alright then
[22:44] <jtaylor> same version in all releases makes it easy :)
[22:45] <eridu> how were you able to tell that?
[22:46] <eridu> I remember putting my name on a wiki page as the bug monitor or something for the pidgin-otr package, so I felt obligated to do something
[22:46] <jtaylor> debfxs has posted a patch
[22:47] <jtaylor> and forwarded to debian and ack'ed thare
[22:49] <Resistance> anyone able to help me figure out why the heck when i pbuilder --login to the chroot, and change the apt sources.list file, the changes dont take?
[22:49] <ajmitch> Resistance: forgot --save-after-login ?
[22:49] <Resistance> ahhh
[22:49] <jtaylor> use --save-after-login
[22:49] <Resistance> probably
[22:49] <Resistance> thanks
[22:50] <Resistance> any way to tell pbuilder to automatically use that when i use the login command?
[22:51] <jtaylor> you shouldn't
[22:51] <Resistance> okay then
[22:51] <Resistance> i wont :)
[22:51] <jtaylor> pbuild is supposed to provide the same (clean) environment each time
[22:51] <Resistance> jtaylor:  i had to enable universe / multiverse
[22:51] <Resistance> so...
[22:51] <Resistance> :P
[22:51] <jtaylor> you can do that during creation with COMPONENTS
[22:52] <jtaylor> e.g. in pbuilderrc: COMPONENTS="main restricted universe multiverse"
[22:53] <Resistance> huh
[22:53] <Resistance> that's in my pbuilderrc
[22:53] <Resistance> and its not listening each time i create the environment :/
[22:53]  * Resistance smells a bug that's specific to his system
[23:29] <Resistance> have the guidelines for requesting a backport changed much since Precise was released?
[23:29] <micahg> Resistance: use requestbackport :)
[23:29] <Resistance> micahg:  ugh, why the heck do i keep forgetting requestbackport
[23:29] <Resistance> oh right, because it segv's on this system
[23:30]  * Resistance has a slighitly-busted system
[23:30]  * Resistance goes off to reinstall Precise
[23:31] <Resistance> actually...
[23:31]  * Resistance just reinstalls the program that was causing problems
[23:32] <Resistance> anyways, micahg, i guess that if i'm waiting for a build to finish on a PPA (so I can test the backport), then the request will just sit there until i confirm it works?
[23:33] <micahg> Resistance: yes, just note in the description what you're planning
[23:34] <Resistance> the heck...?
[23:34] <Resistance> micahg:  requestbackport doesnt run as a user that isnt the user running it, right?
[23:34] <micahg> AFAIK, runs as the current user in the shell
[23:34] <Resistance> hmmmmm
[23:34] <Resistance> that's interesting
[23:34] <Resistance> because...
[23:35] <Resistance> the system isnt unlocking my keyring (even though i've already unlocked it today)
[23:35] <Resistance> and this system isnt auto-login
[23:35] <Resistance> :/
[23:35] <Resistance> its as if its running as some other user
[23:35] <Resistance> (passcode isnt working)
[23:35] <Resistance> oh, and apport is complaining because i cancelled
[23:35] <Resistance> how wonderful
[23:35] <tumbleweed> it's a terminal in X? No ssh or screen or anything like that?
[23:36] <Resistance> tumbleweed:  gnome-terminal
[23:36] <Resistance> within Ubuntu 12.04
[23:36]  * Resistance is confused
[23:37] <Resistance> okay, lemme log out and log back in
[23:37] <tumbleweed> sounds sensible
[23:37] <tumbleweed> FWIW python-keyring (or something below it) does seem to be a bit buggy
[23:38] <Resistance> that might be where the error is occuring
[23:38] <Resistance> perhaps this needs a bug filed against python-keyring?
[23:39] <tumbleweed> we know about the issue, just don't know what causes it
[23:39] <tumbleweed> something throws IOErrors when accessing the keyring every know and then
[23:39] <Resistance> well then this sucks, because the error i'm having is authing LP API access from my system
[23:39] <tumbleweed> you still having trouble?
[23:40] <Resistance> i cleared all the old auths, trying one last time before i shoot the auth system
[23:40] <Resistance> yep, still having trouble
[23:40] <Resistance> want the scrollbacks?
[23:41] <Resistance> s/scrollbacks./
[23:41] <Resistance> bleh
[23:41] <Resistance> i meant the trace
[23:41] <tumbleweed> yes please
[23:41] <Resistance> i could generate an apport if necessary, do yo uneed that, or no?
[23:41] <tumbleweed> let's see the traceback first
[23:42] <Resistance> wait...
[23:42] <Resistance> what the...?
[23:43] <Resistance> oh
[23:43] <Resistance> right
[23:43]  * Resistance ignores that error, and removes the package  being the problem
[23:43] <Resistance> anyways, that trace
[23:47] <Resistance> tumbleweed:  https://pastebin.com/Y1Sh0LEE
[23:47] <Resistance> bleh
[23:47] <Resistance> without the https://, but with http://
[23:48] <Resistance> tumbleweed:  the "error" is a GUI one: it pops up a box asking for me to put the passcode in for the keyring, but...
[23:48] <tumbleweed> Resistance: right, that traceback doesn't help much, but your description does shed some light
[23:48] <tumbleweed> is the keyring working for other things?
[23:48] <tumbleweed> such as network-manager
[23:48] <Resistance> its error says the passcode for the keyring unlock is invalid, and needs to be reentered
[23:48] <Resistance> and that point it does not worik
[23:48] <Resistance> and yes, it works with network-manager, and packaging signing (GPG)
[23:49] <Resistance> s/GPG/PGP/
[23:49] <Resistance> (since my PGP key is in my keyring)
[23:49] <tumbleweed> package signing doesn't use the gnome-keyring
[23:49] <Resistance> *shrugs*
[23:49] <Resistance> network-manager's working
[23:49] <Resistance> and its unlocked and works at-login
[23:49] <tumbleweed> can you browse the keys in seahorse (parsswords tab)
[23:49] <Resistance> what keys?
[23:50] <Resistance> :/
[23:50] <Resistance> oh wait a minute
[23:50] <Resistance> *that* isnt unlocking...
[23:50] <Resistance> what the hell?
[23:50] <Resistance> bleh
[23:51] <Resistance> how do i fix that then
[23:51] <tumbleweed> delete the keyring?
[23:51] <tumbleweed> it's in ~/.gnome2/keyrings/
[23:51] <tumbleweed> (back it up first, of course)
[23:51] <Resistance> back it up, even though its empty?
[23:51] <Resistance> this is a new installation of precise
[23:51] <Resistance> :/
[23:51] <tumbleweed> then just delete it
[23:52] <tumbleweed> when you create a new one, use your login password and it should unlock automatically
[23:53] <Resistance> ah that worked
[23:53] <Resistance> yeah, the passcode for the network i'm on right now in network-manager is available system-wide, so its pulling from the shared keyrings, not my local one
[23:54] <Resistance> s/local/personal/.
[23:58] <Resistance> tumbleweed:  are you a backporter, or should I stab micahg?
[23:59]  * micahg puts on a suit of armor
[23:59]  * tumbleweed is not a backporter. I just hang out with them :)
[23:59] <Resistance> :P
[23:59] <Resistance> okay then
[23:59] <Resistance> micahg:  https://bugs.launchpad.net/precise-backports/+bug/1000492  i can't test certain packages
[23:59] <Resistance> as the dependency for certain packages there is to have certain card architectures i dont have
[23:59] <tumbleweed> Resistance: looks like you still have lots of testing to do
[23:59] <Resistance> namely the nvidia-cuda one
[23:59] <Resistance> tumbleweed:  read the description / testing area