[01:15] <kamal> micahg: thanks for all the syncs :-)    ... did this one get missed though?  bug 926753
[01:16] <micahg> I didn't see it in the queue
[01:16] <micahg> kamal: ah, porthose is still doing things the old way, I can sync that now
[01:16] <kamal> micahg: porthose did something ...
[01:16] <kamal> yeah
[01:17] <kamal> micahg: thanks again!  :-)
[01:17] <micahg> kamal: thank you for keeping Ubuntu up to date, and if you're interested in a ham radio packageset, we could probably do that as I know we have  a few Ubuntu people interested in that stuff
[01:18] <kamal> micahg: I don't know what a "packageset" would mean/entail/do ... googling
[01:18] <micahg> kamal: https://wiki.ubuntu.com/UbuntuDevelopers#Ubuntu_Developers_.28from_delegated_teams.29
[01:19] <kamal> micahg: ok, with upload rights for that set of packages then?   hmmm.   scary.   ;-)
[01:19] <micahg> kamal: if this works for you, no problem
[01:20] <micahg> just offering if you want it one day
[01:20] <kamal> micahg: honestly, I like the added buffer/sanity-check that sponsored uploads provides, but maybe I'm just being wimpy.  I will discuss it with a couple of the other ubuntu-hams principals and get back to you.  thanks!
[03:14] <epikvision> hello
[03:14] <epikvision> can anyone help me get started
[03:14] <epikvision> I'm new and want to contribute as developer
[12:15] <MaximLevitsky> I don't know if this is the right place to ask, but I have a problem with multiarch support in 12.04.
[12:16] <MaximLevitsky> I have bunch of -dev packages that I need both x64 and i386 versions, but they conflict because both contain same headers
[12:16] <MaximLevitsky> Is this issue known?
[12:17] <tumbleweed> MaximLevitsky: either the headers need to be identical, or they must be moved to a multi-arch path so they don't clash
[12:17] <MaximLevitsky> I am pretty sure that headers are identical, but dpkg still refuses to install them
[12:18] <MaximLevitsky> You mean that dpkg actually compares the headers or package is marked as having same headers?
[12:19] <MaximLevitsky> I have problem with bunch of X11 libraries
[12:20] <tumbleweed> yes
[12:21] <tumbleweed> I assume you have read http://wiki.debian.org/Multiarch/Implementation ?
[12:26] <MaximLevitsky> I didn't. Anyway all I needed to know if this is a generic package system wide issue or just specific package bug. Since its the second, I guess its mostly offtopic here
[12:26] <wzssyqa> https://bugs.launchpad.net/ubuntu/+source/ns2/+bug/928193
[12:26] <wzssyqa> somebody help to SRU?
[12:30] <tumbleweed> what needs to be rebuilt, ns2 or nam?
[12:31] <wzssyqa> tumbleweed: nam
[12:31]  * tumbleweed deletes the ns2 task
[12:32] <tumbleweed> wzssyqa: can you provide a test case in the bug?
[12:32] <wzssyqa> tumbleweed: test case?
[12:33] <tumbleweed> wzssyqa: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
[12:34] <geser> short step-by-step tutorial how to reproduce it and to check that it works (with the patched package)
[12:40] <wzssyqa> tumbleweed: I mark it invalid for ns2
[12:41] <wzssyqa> tumbleweed: test case is posted
[12:44] <tumbleweed> wzssyqa: thanks
[12:55] <tumbleweed> wzssyqa: to avoid that in the future, will you add a Breaks on newer tcl?
[12:55] <wzssyqa> tumbleweed: y, I have do it.
[12:56] <tumbleweed> wzssyqa: uploaded
[12:56] <wzssyqa> tumbleweed: many thx
[15:41]  * achiang uses requestsync, and it talks about a "new keyring". what is it talking about?
[15:43] <achiang> perhaps it is related to launchpadlib? i see a new ~/crypted_pass.cfg appeared
[15:51] <tumbleweed> achiang: yes. headless?
[15:51] <achiang> tumbleweed: yeah, headless
[15:51] <achiang> (although i must give kudos to w3m for just working)
[15:52] <tumbleweed> heh, I normally copy and paste the URL to my local browser
[15:53] <tumbleweed> in a desktop environment that'd be in the gnome/kde keyring. (and you don't need to do it on a remote box just because of e-mail/gpg, the API is default these days)
[18:04] <jtaylor> why wasn't bug 889241 fixed by the lastest nunit upload? it had LP:#xx in the changelog
[18:07] <Ampelbein> jtaylor: launchpad also matches the sourcepackagename
[18:09] <Ampelbein> (a upload of $PACKAGE_A can't close bugs in $PACKAGE_B)
[18:16] <directhex> yikes. jtaylor, can you sync cli-common into precise? 0.8~xamarin1 is bug city
[18:16] <jtaylor> directhex: its main, I have no rights there :(
[18:16] <jtaylor> file a request with requestsync
[18:17] <directhex> argle
[18:17] <Laney> just do syncpackage
[18:18] <Laney> surely we can upload it
[18:18] <micahg> yes, you ca
[18:18] <micahg> *can
[18:18] <directhex> syncpackage: Error: Source package cli-common is blacklisted.
[18:18] <jtaylor> if I do syncpackage I get no rights to upload
[18:18] <directhex> so why's it moaning?
[18:18] <jtaylor> I tried that with nunit
[18:18] <jtaylor> which is also main
[18:18] <Laney> you aren't in cli-mono-dev
[18:18] <Laney> but we are
[18:19] <directhex> why isn't jtaylor in cli-mono-dev?
[18:19] <Laney> he hasn't applied
[18:19] <Laney> dear edit_acl. please work, thanks.
[18:19] <jtaylor> I didn't even know it exists :)
[18:19]  * micahg doesn't see cli-common on the sync blacklist
[18:19] <Laney> probably current
[18:19] <Laney> --force it
[18:19] <directhex> jtaylor, mono is a packageset, so in theory group members can poke the named packages without main upload rights
[18:20] <directhex> syncpackage: Request succeeded; you should get an e-mail once it is processed.
[18:20] <jtaylor> that would be nice, then I don't need a sponsor for the nunit fix :)
[18:20] <jtaylor> I'll apply in a moment
[18:20]  * micahg hopes a test build was done first :)
[18:21] <directhex> micahg, it's perl. not much building involved
[18:21] <micahg> directhex: I can show you lots of perl build failures :)
[18:21] <directhex> sounds like evil perl
[18:21] <directhex> dpkg-deb: building package `ikvm' in `../ikvm_7.0.4335.0+ds-5ubuntu1_all.deb'.
[18:21] <directhex> ;D
[18:22] <directhex> relatedly, this package needs cli-common-dev >=0.8~xamarin2 to build, which isn't in precise
[18:22] <directhex> yet
[18:22] <directhex> hence noticing & the sync talk
[18:22]  * ajmitch hates coming across packages that pkg-cli-apps look after that seem to be dead upstream - like tasque
[18:22] <directhex> ajmitch, a bit sad
[18:22] <directhex> ajmitch, but users, so...
[18:22] <micahg> directhex: that's why test builds are important :)
[18:23] <blackz> hi
[18:23] <ajmitch> directhex: yeah, I saw some people complaining on a bug about unity indicator support, patch has been in upstream bugzilla for 7 months with no comment
[18:23] <micahg> hi blackz
[18:23] <blackz> hey micahg
[18:23] <blackz> late congrats for you core-dev membership :)
[18:24] <micahg> blackz: thanks, are you back, or just visiting?
[18:24] <Laney> yeah, it is actually only the finest quality perl
[18:24] <Laney> from waitrose and m&s
[18:24] <blackz> micahg: heh I'd say I'm back now ;)
[18:25] <micahg> blackz: awesome :), there's plenty to do, and we still need lots of help, welcome back
[18:27] <blackz> micahg: yeah I seen
[18:28] <blackz> micahg: thanks :)
[18:38] <jtaylor> Laney, directhex: https://code.launchpad.net/~jtaylor/ubuntu/oneiric/nunit/fix-889241/+merge/91895
[18:40] <Laney> why is it forwarded: no?
[18:40] <directhex> Laney, because it's cherry picked from upstream i guess?
[18:41] <directhex> jtaylor, seems you've got .pc cruft in your diff
[18:41] <Laney> should be not-needed then
[18:41] <jtaylor> thats how bzr works ._.
[18:41] <jtaylor> I haven'T forwarded it yet, but probably should be
[18:41] <jtaylor> so no
[18:41] <jtaylor> though I can probably do it
[18:42] <jtaylor> the issue is I don't really know if its a bug or monodevelop using it wrong
[18:42] <Laney> well speaking to upstream helps to clarify that
[18:42] <jtaylor> yes that is on my todo list
[18:42] <Laney> I saw another patch of yours that wasn't forwarded too but I forgot where it is now
[18:42] <jtaylor> in a mono package?
[18:43] <Laney> yeah
[18:43] <Laney> well it was Forwarded: no
[18:43] <jtaylor> I haven'T got a checkout to grep :/
[18:54] <jtaylor> forwarded it and added tags
[18:55] <Laney> the fix needs to be in the dev release first too
[18:55] <Laney> is it worth waiting for an upstream response?
[18:55] <jtaylor> it is
[18:55] <Laney> ?
[18:55] <Laney> then what did you forward?
[18:57] <jtaylor> the patch
[18:57] <jtaylor> its already applied in debian and precise
[18:57] <Laney> maybe it was that that i saw then
[18:58]  * Laney . o O ( who-uploads nunit )
[19:01] <jtaylor> its be better to wait for upstream response for the SRU
[19:02] <Laney> yes
[19:03] <jtaylor> I set the merge to wip
[19:31] <jtaylor> tumbleweed, barry: whats your take on getting numpy 1.6 into precise?
[19:52] <barry> jtaylor: i don't have any particularly strong opinions about it, but i see that 1:1.6.1-3 has hit experimental.  maybe you could take a look at the rdepends and see if they are compatible with 1.6?
[19:53] <barry> jtaylor: it would have to happen before feature freeze
[19:53] <jtaylor> debian is transitioning right after hdf5 is done
[19:53] <jtaylor> 1.6 is compatible
[19:53] <jtaylor> only ~15 rdepends to rebuild
[19:54] <barry> what's up with hdf5?
[19:54] <jtaylor> I didn't rebuild them in ubuntu yet, but morph did in debian and said no failures
[19:55] <jtaylor> there where a bunch of issues with it on other arches, I think they are rresolved but its still moving slowly
[19:55] <jtaylor> all those science packages aren'T easy to deal with
[19:55] <barry> yeah
[19:55] <jtaylor> @hdf5
[19:56] <barry> which arches are broken?
[19:56] <jtaylor> I think mips was one problem, I'm not to familiar with the progress
[19:56] <jtaylor> its not feasable to do that transition in ubuntu before the feature freeze
[19:57] <barry> jtaylor: in that case, i think it's best to wait for q-series.  we need stability in the lts and i'm worried about such a big change after ff
[19:58] <jtaylor> numpy you mean?
[19:58] <barry> that's what you were referring as being "not feasible", right?
[19:58] <jtaylor> no hdf5
[19:58] <barry> ah
[19:59] <jtaylor> numpy packages needing rebuild: http://people.canonical.com/~ubuntu-archive/transitions/numpy.html
[20:01] <barry> it's a trade-off (and tough call) i guess.  erring on the side of stability vs. having an old version in an lts.  if we have high confidence that hdf5 will be fixed before beta 1, then maybe it would be okay
[20:02] <jtaylor> we don't need hdf5 for numpy
[20:02] <jtaylor> at least thats my understanding
[20:02] <barry> right, but we don't want a broken hdf5 in an lts
[20:02] <jtaylor> its just ongoing and conflicts with numpy
[20:02] <jtaylor> is it broken?
[20:02] <barry> sorry, am i misunderstanding?  i thought you said it was incompatible w/ numpy 1.6
[20:03] <jtaylor> no I only said debian will transition numy when they are done with hdf5
[20:03] <barry> oh, gotcha
[20:03] <jtaylor> sorry for being confusing :)
[20:03] <barry> no, it's probably me :0
[20:03] <barry> er, :)
[20:03] <barry> i'd say double check w/doko, but if he has no objections, it's fine with me
[20:51] <tumbleweed> jtaylor: the entire transitions don't have to happen before FF, but should be started before FF
[20:52] <jtaylor> thats good news
[20:52] <tumbleweed> barry: the pypy currently in NEW (it was deleted by accident) should work with normal virtualenv
[20:52] <barry> tumbleweed: nice!
[20:53] <jtaylor> I'd also still like to have the new sphinx in precise, the last blocker seems to be fixed soon
[20:53]  * tumbleweed hopes to have pypy 1.8 soon
[20:53] <jtaylor> would probably make sense to do that before numpy to get the docs of the rebuilds built with the new sphinx
[20:53] <tumbleweed> which means I need to start putting effort into modules...
[20:53] <barry> jtaylor: +1 for sphinx.  are you going to work on that?
[20:54] <tumbleweed> jtaylor: yeah, that would be nice too
[20:54] <jtaylor> barry: jwilk did all the work in debian, it probably only needs syncing
[20:54] <barry> jtaylor: let me take a look
[20:54] <jtaylor> there are a few packages broken still that need syncing too
[20:54] <jtaylor> there is a open request with all info
[20:55] <barry> jtaylor: bug #?
[20:55] <jtaylor> would have to look it up (if lp lets me :/)
[20:56] <jtaylor> bug 911124
[20:57] <barry> jtaylor: cool, i'll work on that when i'm done with my current packaging
[20:57] <jtaylor> no rebuild was done in ubuntu, but I guess any issue that still might come up can be fixed in time
[21:50] <pabelanger> howdy
[21:51] <pabelanger> I have a debdiff for bug 928499 to fix a comping issue with DKMS and DAHDI
[22:09] <Corey> I have a links file that contains the line usr/lib/python2*/dist-packages/salt/salt-minion /usr/bin/salt-minion; how do I get it to *properly* expand the 2* to either 2.6 or 2.7 (depending upon which version is on the system in question)?
[22:14] <jtaylor> why is the executable in lib/python2 in the first place?
[22:14] <Corey> jtaylor: Where should it live instead?
[22:14] <Corey> /usr/share/salt/ ?
[22:14] <jtaylor>  /usr/bin
[22:15] <Corey> jtaylor: That's not how similar packages do that, /usr/bin/ contains a fair number of symlinks to other places.
[22:15] <jtaylor> not many
[22:16] <jtaylor> in most cases it are links to alternatives
[22:16] <Corey> jtaylor: Better to just drop the binary into place then?
[22:16] <jtaylor> but shellscripts calling stuff in lib is common yes, but not for python
[22:16] <jtaylor> in this way
[22:16] <jtaylor> that probably makes most sense
[22:17] <jtaylor> what is that file? a modules + main section or only the main
[22:19] <Corey> jtaylor: Script that invokes a bunch of stuff in the usr/lib/python2*/dist-packages/salt/ directory.
[22:19] <jtaylor> thats fine
[22:19] <jtaylor> it would be a bit strange if it also was intended an importable modules too
[22:20] <Corey> jtaylor: Yeah, it provides an entire API for python programs.
[22:20] <Corey> It's concieved as an extensible configuration mangement tool.
[22:20] <jtaylor> this one script?
[22:21] <jtaylor> is it a large file?
[22:23] <Corey> jtaylor: No, just does an import salt and defines the main function.
[22:24] <jtaylor> then don't install it in lib, but in bin instead
[22:25] <quadrispro> jtaylor, thanks for that mail about the FTBFS ;)
[22:26] <quadrispro> I'm very busy these days, I've miss'd 'em
[22:26] <jtaylor> quadrispro: which one?
[22:27] <quadrispro> jtaylor, the only one mail :) stk and lv2proc
[22:27] <quadrispro> jtaylor, you gave me the opportunity to find a most important in rtmidi
[22:28] <quadrispro> important bug, I meant
[22:30] <jtaylor> quadrispro: how did my mail help find a bug o_O
[22:31] <quadrispro> jtaylor, stk's ftbfs was due to a uncorrect linking against rtmidi
[22:32] <quadrispro> so your help has been much appreciated :)
[22:32] <quadrispro> keep up the great work
[22:33] <micahg> quadrispro: I still have gmusicbrowser on my list, I just have to get a key on alioth so I can push to git
[22:33] <jtaylor> np, thanks for fixing the ftbs
[22:33] <quadrispro> bdrung, eh-ehy! already commit'd, now I'm going to add a point to the next changelog entry
[22:34] <quadrispro> hi micahg ! did upstream release a new version?
[22:34] <micahg> yeah, 1.1.9
[22:34] <quadrispro> well, yes
[22:34] <quadrispro> git-import'ing right now
[22:34] <quadrispro> micahg, have you already had a look at the code?
[22:35] <micahg> no, not yet, got as far as the checkout failing due to not being able to do it without an SSH key
[22:36] <micahg> well, actually I got the checkout, not the upstream branch I needed to do the import
[22:36] <micahg> I can fix it, but moved on to other things
[22:37] <quadrispro> wow, gmusicbrowser is getting very cool
[22:37] <micahg> quadrispro: one of these days I'll get the hang of git
[22:37] <quadrispro> micahg, mostly bugfixes plus various small improvements
[22:37] <micahg> yep, xubuntu wants it for precise
[22:38] <micahg> and astraljava wants a backport for oneiric
[22:38] <quadrispro> micahg, lol, are you still in trouble? have you uploaded your key to alioth?
[22:38] <micahg> no, I got distracted by other things, I'll look into it later
[22:38] <quadrispro> you should wait for some hours after uploading the key I suppose
[22:38] <quadrispro> ah ok ok
[22:39] <quadrispro> no worries, here is Alessio who's happy to share some of his spare time tonite
[22:39] <jtaylor> @numpy, I rebuilt the 16 of the 18 packages in precise and they build fine
[22:40] <jtaylor> I skipped shogun as it takes ages to build and one needs a manual dependency resolving for which I'm to tired to do now ._.
[22:41] <jtaylor> (pandas, needs scipy and pytables rebuilt)
[23:01] <tumbleweed> quadrispro: think that was the same bug as bug 423609? (it looks like it)
[23:03] <psusi> whois smoser smoser
[23:03] <quadrispro> hi tumbleweed! you mean LP: #423609?
[23:03] <Corey> Assuming that debian/rules doesn't make reference to it, how does a package install know what services to start / how does it invoke them?  The install throws a race-condition type error, like it's trying to start before fully installed, but once it's installed it works properly.
[23:04] <tumbleweed> quadrispro: yup
[23:04] <quadrispro> yes, you meant so :) and yes, it looks the same
[23:04] <tumbleweed> great, I thought I'd remembered seeing someone complaing about us not setting DISTRIBUTION before
[23:04] <tumbleweed> I thought they were crazy, but it appears that cowubilder needs it :P
[23:05] <quadrispro> tumbleweed, and I think DIST and ARCH are mere alias recommended by PbuilderTricks page on the Debian's wiki
[23:05] <tumbleweed> yes
[23:05] <quadrispro> skipped by pbuilder though
[23:05] <tumbleweed> the only reason we set them was for people who had interesting pbuilderrcs
[23:05] <tumbleweed> it also passes --distribution
[23:05] <quadrispro> yes, I see
[23:06] <tumbleweed> (oh, and you forgot to close the bug in the changelog :) )
[23:07] <quadrispro> tumbleweed, I haven't yet added any entry
[23:09] <quadrispro> tumbleweed, I need some minutes to fix a big issue on zita-resampler
[23:09] <tumbleweed> quadrispro: I finished itp
[23:09] <tumbleweed> it up
[23:11] <quadrispro> tumbleweed, thank you!
[23:11] <tumbleweed> np, thanks