[00:15] <james_w> zyga, I don't think it does. I'm not sure if it would be hard to add if there's a good way to detect what should be  built for python 3 vs 2. It also depends on the level of support that debhelper has for py3
[00:27]  * doko never wanted to learn that much about m68k and powerpc ...
[00:28] <xnox> =))) lol what did doko just do?
[00:29] <doko> gcc multiarch upstream patches
[00:29] <xnox> james_w: debhelper has no support for py3, but it's a mere 6 or so monkey patch lines across many packages.
[00:30] <xnox> james_w: if there is ported code, I offer services of fast python3 packaging into ubuntu & debian archives =)
[00:30] <james_w> xnox, in debian/rules?
[00:30] <xnox> james_w: yeap.
[00:30] <james_w> might be feasible to do in pkgme then
[00:31] <james_w> xnox, also, go to bed :-)
[00:31] <xnox> james_w: oh for pkgme..... *sigh* we should do better than monkey patching.
[00:31] <xnox> james_w: currently it looks like so: http://wiki.debian.org/Python/LibraryStyleGuide
[00:31] <james_w> aha, great info, thanks
[00:32] <xnox> james_w: but you can get away with less.
[00:33] <xnox> james_w: by supporting only python2.7 & python3 and not compiling / testing under non-default python versions.
[00:33] <xnox> james_w: then it can be compressed further down.
[00:33]  * xnox has no clue what pkgme does or looks like though =)
[00:33] <james_w> hmm, probably quite tricky for pkgme to detect, but good to know
[00:34] <james_w> it's magic :-)
[00:34] <xnox> james_w: well, pure python vs non-pure python =)
[00:34] <james_w> ah, yeah
[00:34] <xnox> james_w: here is smaller case: http://wiki.debian.org/Python/AppStyleGuide
[00:35] <xnox> ideally debhelper python3 support should be written.....
[00:35] <james_w> yeah
[00:52] <mahmoh> hallyn: re: LP#589063, on vaca but I can try next week when I get back?
[00:54] <TheMuso> Hrm thats weird, the 3.7 kernel I have here shows overlayfs built in the kernel, according to the config, but the module is not present in the modules dir...
[00:54] <TheMuso> s/built into the kernel/built as a module/
[01:04] <jelmer> one of my uploads to precise-proposed was just rejected, after being pending for a couple of weeks. Is there any way to find out why?
[01:04] <TheMuso> Was a comment not left in the bug?
[01:06] <TheMuso> Ah, disabled in the kernel source for now.
[01:09] <TheMuso> ...which means non-functioning live images from today onwards or so...
[01:22] <cjwatson> TheMuso: !  I'll have to talk with the kernel team tomorrow about that ...
[01:22] <cjwatson> So much for zero regressions
[01:24]  * TheMuso only found out because he went to use sbuild with an overlay.~s
[01:24] <sarnold> cjwatson: at least it's a big one :)
[01:24] <doko> slangasek, do you think we would need unversioned Multi-Arch same libgcc-dev, libstdc++-dev, libobjc-dev, libgfortran-dev packages?
[01:27] <doko> cjwatson, today I accepted new binary packages for gcc-4.7, zlib, ncurses and readline6, which did all land in main without any further interaction. is this intended?
[01:27] <doko> slangasek, do you think we would need unversioned Multi-Arch same libgcc-dev, libstdc++-dev, libobjc-dev, libgfortran-dev packages?
[01:29] <cjwatson> doko: Yes
[01:29] <cjwatson> doko: Binaries now default to the component of the source
[01:29] <cjwatson> doko: This was a long-standing irritation that we'd been begging to get fixed for ages
[01:30] <doko> not sure if I like this
[01:30] <cjwatson> doko: So you now get the other side of it :-)  I'm pretty certain this is a relatively rare case and in any case component-mismatches handles it
[01:30] <cjwatson> doko: If you wanted them in universe you could always pay more attention when NEWing ;-)
[01:31] <cjwatson> doko: It was really common for people to accidentally NEW library ABI changes of sources in main into universe, causing uninstallability
[01:31] <doko> cjwatson, well, the thing is that the mir team doesn't get any notice about that
[01:31] <cjwatson> doko: The MIR team is not supposed to get notice of *binary-only* changes
[01:31] <doko> no, that's wrong
[01:31] <cjwatson> Binaries of sources in universe still default to universe
[01:32] <doko> if something is split out because we don't want to support it, it should default to universe
[01:32] <cjwatson> Nevertheless, there is no MIR process for this
[01:32] <cjwatson> Sorry, but you just need to catch this manually
[01:32] <doko> sorry, impossible
[01:32] <cjwatson> Certainly not
[01:32] <cjwatson> Somebody could write a script with a blacklist, for instance
[01:33] <doko> "somebody"
[01:33] <cjwatson> The MIR team has never effectively communicated the list of binaries they didn't want in main to the archive team
[01:33] <cjwatson> So if binaries that you didn't want stayed out of main, it was by purest luck
[01:33] <doko> well, I think we should have such a list
[01:33] <cjwatson> Patches to component-mismatches would be a reasonable way to implement such a blacklilst
[01:33] <cjwatson> And I think it would be a good idea
[01:34] <cjwatson> But I really think this Launchpad change is a very substantial net positive
[01:34] <jelmer> TheMuso: no, none of the three associated bugs have a comment about it
[01:34] <cjwatson> The number of binaries from sources in main that we don't want in main is a tiny fraction of the total
[01:34] <micahg> +1, all the new firefox/thunderbird langpacks won't need component massaging
[01:34] <cjwatson> It pretty much has to be since hardly anyone knows what it is
[01:35] <cjwatson> langpacks, new libraries, kernel packages in SRUs (the kernel team had gone so far as to create a watchdog bot to make sure that overrides were right!), ...
[01:37]  * xnox now if the watchdog bot is negated, doko will get the underdog bot he wants =))))
[01:38] <doko> go play volley ball ...
[01:39] <cjwatson> doko: It'd be worth at least filing a bug on ubuntu-archive-tools about this; Ursinha is looking for tools work to do :-)
[01:39] <doko> ok, will do tomorrow
[01:40] <doko> today, later
[01:50] <slangasek> doko: I don't know the answer to whether we would need such unversioned -dev packages to be M-A: same; it would depend on what is going to depend on them (or build-depend on them)
[01:51] <doko> well, are packages with a b-d on gfortran currently cross-built?
[01:51] <slangasek> currently, no
[01:52] <doko> but it works for g++, because it's assumed to be available
[01:53] <doko> anway, afk now
[02:24] <hallyn> mahmoh: thanks - hope you're having a blast :)
[03:04] <slangasek> persia: marking your WI on https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-schedule 'done', since I understand from ScottK that this has already happened
[03:05] <RobOakes> Good morning. Does anyone know where I might find an example of how to create a provider plugin for Ubuntu Online Accounts?
[03:06] <RobOakes> I've been working on a desktop app that integrates with ownCloud, and would love to be able to use Online Accounts for managing credentials/integrating with other apps.
[03:07] <RobOakes> I found the developer API documentation, but not a working example which I could modify to fit my own needs.
[03:09] <jbicha> RobOakes: Empathy, Gwibber, and Shotwell all use UOA in Ubuntu
[03:11] <RobOakes> Okay. I suppose I need direction to two resources.
[03:11] <RobOakes> First, the application I'm developing integrates pretty tightly with ownCloud, which does not yet have a plugin for Ubuntu Online Accounts.
[03:12] <RobOakes> Do you know if it is possible to write/install custom plugins for Ubuntu online accounts? This seems to imply that you can: http://developer.ubuntu.com/api/ubuntu-12.10/python/AccountPlugin-1.0.html
[03:13] <RobOakes> But the docs are pretty sparse. I'd really like to look at an example to get up and running.
[05:34] <pitti> Good morning
[05:44] <ion> that
[07:38] <zyga> james_w: I see, thanks
[07:39] <zyga> james_w: I'm not an expert on either pkgme nor py3k packaging but I'm faced with maintaining some packages and I'd like to do it right
[07:39] <zyga> james_w: there are also hybrid packages (2.*+3k) but they are more complicated and, fortunately, not my task today
[08:30] <dholbach> good morning
[08:33] <pitti> hey dholbach
[08:34] <dholbach> hi pitti
[08:36] <zequence> I'm looking at http://dep.debian.net/deps/dep3/ and  https://wiki.ubuntu.com/PackagingGuide/PatchSystems?action=show&redirect=UbuntuDevelopment%2FPatchTaggingGuidelines#Patch_Tagging_Guidelines.
[08:37] <zequence> Where does the meta go?
[08:38] <zequence> Or, where do the dep3 headers go, more specifically?
[08:39] <zequence> Say, I add a patch with edit-patch. How do I bake in the dep headers?
[08:42] <zequence> Just add it manually to debian/pathches/<mypatch> ?
[08:53] <diwic> zequence, I've always added it by manually editing the file. Maybe there is some simpler way.
[08:53] <diwic> zequence, most patch tools, e g quilt, does not overwrite the headers when refreshing, which helps
[09:02] <zequence> diwic: Thanks. I'm currently working on patching jackd2. Will be my first patch.
[09:03] <zequence> diwic: There are a couple of upstream commits that fix the bug where jackdbus doesn't stop properly
[09:03] <zequence> At least it makes qjackctl able to start jack after attempting to stop it
[09:03] <diwic> zequence, that's good to hear
[09:04] <zequence> So, I'm patching raring with it (don't know when next upstream version of jackd2 will arrive, which would include that fix), and then I'd like to get the fix also into 12.10 and 12.04
[09:30] <mlankhorst> anyone on the sru team can help me out a bit?
[09:31] <xnox> mlankhorst: as per https://wiki.ubuntu.com/StableReleaseUpdates#Publishing bdmurray ^
[09:31] <mlankhorst> yeah was just loooking
[09:32] <mlankhorst> bdmurray?
[09:35] <Laney> you might have to wait until a bit later :-)
[09:35] <mlankhorst> yeah
[09:35] <mlankhorst> I want to start uploading the new version fo unrenamed packages for the lts update
[09:35] <mlankhorst> https://lists.ubuntu.com/archives/ubuntu-x/2012-November/001238.html
[09:36] <mlankhorst> but I don't know whether that has to go through SRU or not, and what the paperwork is I need for that. :)
[09:44] <mlankhorst> sru vs technical board I mean
[10:53] <doko> cjwatson, infinity: https://launchpad.net/ubuntu/+source/gccgo-4.7/4.7.2-0ubuntu2
[10:54] <doko> do you understand the message? builds fine locally on p. the only thing odd is an empty Architecture field for the libx32go* packages (which are not built)
[10:56] <infinity> doko: The error message seems reasonably clear.
[10:57] <xnox> doko: but the Architecture field is mandatory on the binary package.
[10:58] <doko> infinity, dude, I wouldn't ask if it was clear to me
[10:58] <infinity> doko: It's the pkg-create-dbgsym version of dh_strip that's complaining, BTW, which is why you're not reproducing, I suspect.
[10:58] <doko> ahh
[10:58] <doko> pitti, trying to be holier than the pope ...
[10:58] <infinity> Heh.
[10:59] <infinity> But yeah, the empty Arch line is the problem, reading the code.
[11:00] <xnox> doko: export NO_PKG_MANGLE=1
[11:00] <infinity> xnox: Eww, no.
[11:00] <xnox> doko: in e2fsprogs: # no chance that pkg-create-dbgsym can cope with this package's manual construction of -dbg
[11:00] <xnox> doko: if you construct the dbg packages yourself, this should be fine.
[11:01] <doko> I think that would be possible, because there are -dbg packages built anyway
[11:01] <infinity> xnox: NO_PKG_MANGLE turns off more than just ddeb creation. :/
[11:01] <xnox> infinity: I know, but there is no variable just to turn off ddebs =`(
[11:02] <doko> and I don't care if gccgo itself has debug information
[11:02] <xnox> infinity: would `NO_PGK_MANGLE=1 dh_strip` work?
[11:02] <pitti> ah, that's because of my super-advanced shell parsing of debian/control :(
[11:02] <infinity> xnox: Yes, that would work.
[11:03] <pitti> xnox: yes
[11:03] <xnox> pitti: and python-debian/apt was not around back then ? =/ I can feel your pain.
[11:03] <pitti> xnox: it's more an issue of avoiding too many/circular dependencies
[11:03] <xnox> yeah....
[11:03] <pitti> that said, a missing Arch: line sounds relatively easy to fix
[11:03] <pitti> we had packages with a duplicate Arch: line, which are really broken
[11:04] <infinity> pitti: Empty, in doko's case, which seems broken anyway.
[11:04] <infinity> (Missing is also broken)
[11:04] <infinity> But yes, congrats on writing a tool that's more pedantic than dpkg. ;)
[11:04] <xnox> infinity: I wonder if there is a message encoded in that field in whitespace: tab-tab-space-tab...... =))))
[11:06] <infinity> doko: I'd either remove the libx32 stanzas from control completely, or give them a bogus arch (the former seems saner).
[11:33] <brendand> aufs mount failed on todays build?
[11:35] <doko> infinity, reupload gccgo-4.7
[11:44] <xnox> brendand: yeap. known problem, but probably we should find a bug number and link it on the iso tracker or something.
[11:44] <Laney> I pinged about that in #-kernel earlier - perhaps apw knows of a bug #
[11:45] <brendand> xnox, probably isn't good either that usb-creator-gtk segfaults at the end of writing the image
[11:46] <apw> Laney, i don't know of a bug number indeed (for the overlayfs/aufs issue) perhaps you could file one for me
[11:46] <apw> Laney, if its not that, remind me
[11:47] <Laney> tis
[11:47] <Laney> brendand: could you?
[11:47] <Laney> I'm not running the right kernel atm
[11:49] <brendand> xnox, apw, Laney - does it have to be with ubuntu-bug??
[11:49] <apw> brendand, nope, just a +filebug will do
[11:53] <zequence> diwic: Would you mind reviewing my branch, and advise before I request a merge for lp:~zequence/ubuntu/raring/jackd2/fix-for-956438
[11:53] <awpeter_> hey guys, i had a real problem installing nvidia drivers now because i couldn't disable nouveau no matter what i tried (purge remove package, blacklist in modprobe) the finally i disabled nouveau on the kernel line in grub with "nouveau.blacklist=yes", so my suggestion is you complement the normal blacklisting with disabling nouvau from grub so other people can avoid this problem
[11:54] <awpeter_> also i mean: disable it when someone is installing an nvidia driver, and remove it again when you remove the nvidia driver, should be easy to implement and would solve a problem imo
[11:56] <apw> awpeter_, i am unsure how blacklist can not work in this scenario, tseliot did you see this in your testing
[11:56] <awpeter_> i tried really
[11:56] <awpeter_> even the nvidia installer
[11:56] <ogra-cb_> apw, it could cause issues if regenerating the initrd failed
[11:56] <awpeter_> added his own file to modprobe
[11:57] <ogra-cb_> or didnt happen at all
[11:57] <tseliot> awpeter_: disabling it in the initramfs is usually enough
[11:57] <apw> those drivers shouldn't be in the initrd for the basic case
[11:57] <ogra-cb_> apw, plymouth doesnt use them ?
[11:57] <apw> plymouth isn't in the initrd by default
[11:58] <tseliot> awpeter_: mixing the nvidia installer with the ubuntu packages will break your system though
[11:58] <ogra-cb_> no, but to get the right framebuffer device the right module needs to be loaded
[11:58] <brendand> jeez, now the image isn't even booting. just the flashing cursor - same image and everything
[11:58] <apw> ogra-cb_, and that occurs in the real root
[11:58]  * ogra-cb_ thought we do that in initrd
[11:59] <awpeter_> tseliot i had the ubuntu packages removed before i installed nvidia
[11:59] <tseliot> ok
[11:59] <apw> only if they have like encrypted root where we need to interact with them before root is available
[11:59] <diwic> zequence, ok, will do in a little while
[11:59] <apw> awpeter_, so this is installing a random nvidia download ?
[11:59] <ogra-cb_> well, ir if some initrd hook sets FRAMEBUFFER_true
[12:00] <ogra-cb_> *or
[12:00] <ogra-cb_> FRAMEBUFFER=true
[12:00] <apw> indeed, still not the default case
[12:00] <awpeter_> apw well not a random, the newest nvidia driver avaiable from nvidia's site
[12:00] <awpeter_> 310.19 i think
[12:00] <awpeter_> was released 2 days ago or so
[12:00] <apw> awpeter_, it is not clear how we are meant to have control over that ?
[12:00] <zequence> diwic: No hurry. PM me if you have any suggestions, etc.
[12:01] <awpeter_> apw i tried to install via jockey and it failed too
[12:01] <awpeter_> so i suppose jockey had the same problem, that nouveau didn't unload
[12:01] <awpeter_> i mean jockey installed but the driver didn't work
[12:01] <awpeter_> let me clarify, i first tried to install via jockey
[12:02] <awpeter_> then removed everything
[12:02] <awpeter_> and tried via nvidia and nvidia's instller told me that nouveau was still loaded and he can;t continue
[12:10] <apw> awpeter_, so if you can install the nvidia driver and then grab the blacklist it made, i would like to see that, and file a bug against, erm, well i guess kmod for now and attach the blacklist saying it doesn't work; and get me the number
[12:11] <awpeter_> apw uh.. i removed the files and made the blacklist file myself to be sure.. also this is working now so to reproduce it i would have to remove the blacklist from grub, update grub, reboot, etc.. =d
[12:12] <apw> awpeter_, your call, as the blacklist in modprobe should work
[12:12] <awpeter_> apw just a question, if update-initramfs wouldn't work, would the blacklist do anything?
[12:13] <apw> awpeter_, i believe you do need to have a rebuilt initrd to get the blacklists
[12:14] <apw> hmmm, is that 100% true
[12:14] <awpeter_> apw just to be clear i'm on elementary luna, but i asked there and they said that they don't change any tools from ubuntu
[12:16] <apw> awpeter_, as nouveau is in the initrd you would have to rebuild that after installation of nvidia i suspect to get the blacklists included if they have changed
[12:16] <apw> awpeter_, i suspect that the nvidia downloader should be doing that
[12:16] <apw> if you get bored you could confirm that doing that sorts you out
[12:17] <awpeter_> apw and i tried to run "sudo update-initramfs -u" but it did nothing
[12:17] <awpeter_> apw so i suppose there was the problem
[12:17] <apw> awpeter_, did nothing as in nothing happened at all, or nothing got better
[12:17] <awpeter_> nothing happened, i hit enter and it didn't process anything
[12:17] <awpeter_> just went straight back to cmd line
[12:18] <apw> apw@dm:~/git2/linux$ sudo update-initramfs -u
[12:18] <apw> [sudo] password for apw:
[12:18] <apw> update-initramfs: Generating /boot/initrd.img-3.5.0-18-generic
[12:18] <apw> well that sounds like something else is broken as it does for me
[12:18] <awpeter_> yeah
[12:18] <apw> so perhaps it does even do the right thing
[12:18] <awpeter_> and i don't want to confuse anybody here but i asked on elementary-dev
[12:19] <awpeter_> and somebody said there they don't change the tools
[12:19] <awpeter_> so it should work like it does on ubuntu 12.10
[12:19] <awpeter_> and updating initram clearly doesn't work for me
[12:20] <awpeter_> so now i don't know if it's their problem or ubuntus =d
[12:20] <awpeter_> or even mine x)
[12:22] <OdyX> tkamppeter: you there?
[12:24] <OdyX> tkamppeter: you know that openprinting forums are not responding ? At least the forums.openprinting.org address that is pointed at by linuxfoundation.org fails.
[12:27] <OdyX> tkamppeter: do you have contacts @ Brother ? It'd be vastly better if they could release their lpr stuff in a more liberal license than "open-source distribution but you only get binaries"
[12:57] <hrw> argh. eglibc now needs libselinux
[13:37] <mahmoh> hallyn: np - I'm trying :)
[13:47] <brendand> apw, i'm raring (:P) to raise this aufs overlay bug, but i forget what the message was and now the image is mysteriously not even getting as far as it did before. do you happen to recall the error shown?
[13:47]  * brendand wonders is his netbooks hdd trashed?
[13:47] <apw> brendand, nope
[13:47] <apw> brendand, just file a generic bug, and i'll figure it out
[13:47] <brendand> apw, crap
[13:47] <brendand> apw, ok
[13:50] <brendand> apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1079193
[14:02] <cjwatson> apw,brendand: Well I mean we shouldn't be touching aufs at all - TheMuso said last night that overlayfs was missing, I assume you've got that far?
[14:03] <apw> cjwatson, yes, i am on the case, i have some builds in testing right now to resolve these issues
[14:03] <apw> cjwatson, the bug is mearly to allow linking to the iso-tracker
[14:03] <cjwatson> Cool
[14:07] <ScottK> xnox: Are you fixing python3-defaults?
[14:07] <ScottK> (bad symlink)
[14:07] <xnox> ScottK: I only confirmed it.
[14:08] <xnox> ScottK: it is urgent?
[14:08] <ScottK> I'm not sure if anything uses that link or not.
[14:08] <ScottK> Should be easy enough to fix.
[14:08] <ScottK> I'll do it if you aren't already.
[14:08] <brendand> cjwatson, i just saw aufs mentioned in the error, sorry if that wasn't accurate
[14:08] <brendand> 'aufs mount failed'
[14:09] <xnox> ScottK: well if anything is using it, it's still screwed cause there is no more "mu" build, only "m" build is left.
[14:09] <xnox> ScottK: and the new correct symlink should be "python3m"
[14:09] <xnox> ScottK: so it's moot point.
[14:09] <ScottK> Right.
[14:09] <xnox> ScottK: the fix should be done in debian's svn python3-default, as it affects them as well.
[14:10] <ScottK> Not yet it doesn't.
[14:10] <ScottK> But you're right, it will.
[14:10] <xnox> ScottK: affects "upstream" code-base, I know they didn't switch yet.
[14:12] <ScottK> It looks to me trivial to fix once 3.3 is the default, but work required to make it OK with either 3.2 or 3.3, so I'll just fix Ubuntu for now.
[14:16] <xnox> ScottK: i wouldn't.
[14:16] <ScottK> Why?
[14:16] <xnox> doko: have you seen bug 1079159 ? ScottK is eager to monkey patch it in ubuntu.
[14:17] <xnox> ScottK: as I said the fix should be done right in debian upstream.
[14:17] <cjwatson> brendand: It's accurate because casper will fall back to aufs if it can't find overlayfs
[14:17] <cjwatson> brendand: But the solution we want is to fix overlayfs
[14:18] <ScottK> doko: moneky patch/fix debian/rules.
[14:18] <xnox> ScottK: and there is no evidence it's causing any problem to anyone because (a) they shouldn't rely on it (b) it will be dropped anyway and (c) there is no rush to introduce a brand new symlink
[14:18] <ScottK> Why will it be dropped anyway?
[14:19] <ScottK> The current dangling symlink is definitely wrong.
[14:20] <xnox> ScottK: there is no "u" build types in python3.3 anymore upstream.
[14:21] <xnox> and the python3 symlink is correct and points to a working python3.3
[14:21] <ScottK> xnox: Sure.  I changed it to properly be python3m -> python3.3m
[14:21] <ScottK> I dropped all the "u"s (and there are several).
[14:21] <ScottK> Including some "dmu"s.
[14:22] <xnox> ScottK: "it will be dropped anyway" i mean the "3mu" droppped, not the general case of $python$version$abiflag
[14:22] <xnox> =))))
[14:22] <ScottK> Ah.  Then we agree about the proper end state.
[14:23] <ScottK> I did not add a link that points python3mu -> python3.3m.  That would be wrong.
[14:25] <xnox> ..
[14:31] <xnox> is there an easy way to query launchpad to give me all versions of a source package ever published in any ubuntu series/pockets?
[14:32] <ScottK> Fixed.
[14:36] <geser> xnox: have you tried the LP API? archive.getPublishedSources() should help your further (pick source_name, distro_series, pocket as needed)
[14:37] <xnox> geser: slowly getting there. Did not realise a hop from distribution["ubuntu"] -> archive[0] for primary....
[14:38] <geser> I usually use distribution['ubuntu'].main_archive to get the Ubuntu archive object
[14:39] <mitya57> xnox: https://launchpad.net/ubuntu/+source/PACKAGE/+publishinghistory ?
[14:39] <xnox> mitya57: i need it on the command line ;-)
[14:39] <xnox> geser: ah nice. thanks.
[14:39] <xnox> geser: got it now.
[14:47] <ScottK> Sweetsha1k: Would you please reupload boost-mpi-source1.49 with the bug in debian/changelog.
[14:47] <ScottK> (quantal-proposed)
[14:49] <cjohnston> Laney: ping
[14:51] <Laney> hi
[14:51] <cjohnston> Laney: trying to follow up on bug #1020592, it's still fix committed, but doesn't seem to be available yet?
[14:52] <Laney> cjohnston: seems to be in precise-backports?
[14:53] <Laney> python-django-auth-openid | 0.4-1ubuntu1~ubuntu12.04.1 | precise-backports/universe | all
[14:53] <cjohnston> ahh.. nvm.. sorry.. was searching openid-auth not auth-openid
[14:53] <Laney> heh
[14:53] <cjohnston> in that case, it can be marked fix committed correct?
[14:53] <Laney> so that bug should be fix released
[14:53] <cjohnston> sorry, released, yes
[14:53] <cjohnston> forgot I changed the package name too. lol
[14:54]  * cjohnston needs to cleanup his backlog of trying to get things backported
[15:07] <tkamppeter> OdyX, I have aded you to the printing team on LP now.
[15:08] <OdyX> tkamppeter: yeah; I don't really know what it can be useful for, but well :-) Did you see my request about Brother above ?
[15:09] <tkamppeter> OdyX, I have contacts to Brother, but for me it seems that they have driver code which they want to keep secret (partially bought from third parties) and open source wrappers to integrate the drivers into Linux environments.
[15:10] <GunnarHj> SpamapS: ping?
[15:10] <doko> ScottK, xnox: thanks
[15:11] <ScottK> doko: You're welcome.
[15:12] <OdyX> tkamppeter: it would be already better if they put all these binaries in nice tarballs that we could package to non-free e.f
[15:12] <OdyX> tkamppeter: same for the cupswrappers, which are free software.
[15:13] <OdyX> tkamppeter: I kinda-understand the need to keep driver stuff private, but it makes their printers x86-limited and badly supported in Linux currently.
[15:14] <OdyX> tkamppeter: the best would be for them to hire someone to do some linux'ish / FLOSS consultancy for the handling of these drivers; I think they can see an interest in having their printers work out-of-the-box on Linuxes.
[15:15] <tkamppeter> OdyX, yes, my HP printers work even on an ARM-based Nexus 7 running Ubuntu.
[15:17] <OdyX> tkamppeter: anyway, to make longs things short: if we can get them release non-free stuff in a better way than hidden in rpms and behind useless GPL click-through, we could have their stuff packaged and shipped in non-free/multiverse, for their benefit.
[15:17] <OdyX> tkamppeter: if you have contacts, I'd be grateful if we could get in touch with them in that direction, I'd be happy to be involved on the technical side.
[15:17] <OdyX> (as installing a Brother printer using stupid  debian packages today annoyed me highly)
[15:18] <OdyX> tkamppeter: ah, my other concern was the forum.openprinting.org, linked from linuxfoundation.org, but not accessible :)
[15:19] <tkamppeter> OdyX, I need to re-install that.
[15:21] <OdyX> tkamppeter: ah okay, as long as you're aware.
[15:21] <OdyX> tkamppeter: for this Brother thing, is that something you plan to do or you'd prefer to let me handle it (using your sicritz contacts) ?
[15:22] <OdyX> you have the linuxfoundation lever, probably longer than my debian lever :)
[15:35] <_val_> Hi. Thanks for packaging the spice-xpi plugin for mozilla firefox. There seems to be a bug. Is someone aware of this bug?
[15:36] <smartboyhw> _val_, then report a bug against it......
[15:37] <_val_> smartboyhw: Problem is that it only shows to dismiss or report the bug. When clicking on the link to report the bug it explains what a bug is.
[15:37] <smartboyhw> _val_, what?
[15:39] <_val_> smartboyhw: going to make another attempt :>
[15:40] <achiang> hi, in general if a lower level library gets updated in the archive, does that necessarily imply a rebuild for all its rdepends?
[15:41] <achiang> question applies for things like SRUs, security updates, etc.
[15:41] <achiang> jdstrand: ^^
[15:42] <SpamapS> Laney: re copying webkit.. its my understanding that we shouldn't be copying packages that have arch: any binary packages because the toolchain is newer in raring.
[15:42] <OdyX> achiang: afaik no.
[15:42] <jdstrand> achiang: not unless there is an abi change
[15:42] <SpamapS> Laney: I assume this is especially important for armhf binaries
[15:42] <jdstrand> achiang: and we very much try to avoid those in updates
[15:42] <achiang> ah, that's good to know.
[15:43] <achiang> so is that different from the early days of a release when the archive is rebuilding then? what is that all about?
[15:43] <jdstrand> achiang: sometimes it is unavoidable, like with how we are updating webkit, but by and large, that is not the norm
[15:43] <SpamapS> GunnarHj: pong, whats up?
[15:45] <achiang> jdstrand: makes sense. but we do rebuild the archive for days at a time usually right before UDS, and i'd like to know what that's for. :)
[15:45] <jdstrand> I think that is more bootstrapping the toolchain and libc and stuff
[15:46] <achiang> so everything built afterwards *does* have the proper ABI, yeah?
[15:46] <jdstrand> but yeah, there are abi changes in that process, so things have to be rebuilt
[15:46] <SpamapS> achiang: thats for ABI library transitions too
[15:47] <SpamapS> but sometimes there are library transitions later, and thats where you see smaller rebuilds
[15:47] <jdstrand> achiang: but that is the dev release, not a stable release. different rules and processes there
[15:47] <achiang> is there a convention in d/changelog or package name if an ABI change occurs?
[15:48] <jdstrand> not that I know of
[15:48] <achiang> hm, ok
[15:48] <GunnarHj> SpamapS: Hi Clint, and thanks for uploading the fix of bug 875435 to quantal-proposed yesterday. There are branches with identical changes in the Precise and Oneiric queues. Would you mind to upload also those, in order to simplify the verification process?
[15:49] <SpamapS> achiang: the convention is to name the library package after the ABI version. so for instance libmysqlclient18
[15:49] <achiang> ah!
[15:49] <achiang> ok
[15:49] <SpamapS> achiang: and thats actually fairly important so that you can have the old one around to maintain installability
[15:49] <achiang> jdstrand: SpamapS: thanks, makes sense
[15:50] <SpamapS> GunnarHj: sure I'll review those now
[15:50] <jdstrand> oh, that, yes :)
[15:50] <GunnarHj> SpamapS: Great, thanks!
[15:50] <Laney> SpamapS: hmm, I'm not sure, but anyway I've uploaded a new version to raring now
[15:50] <Laney> thanks for considering it
[16:04] <SpamapS> Laney: a lot of what I said is just my own perception. Others with more intimate knowledge of the archive state may have other opinions.
[16:08] <micahg> _val_: I'm not aware of spice-xpi actually being in the archive
[16:13] <mitya57> ScottK, xnox: I don't see why that shouldn't be committed to Debian. That affects only the default version ($(VER)), which is 3.3 in bzr version.
[16:15] <mitya57> Also, as nobody wants to review my python-defaults merge, I've subscribed ~ubuntu-branches there.
[16:17] <ScottK> mitya57: Sure (re Debian), but there's no rush.  Since I'm one of the maintainers there, I'll take care of it eventually.
[16:18] <mitya57> OK.
[16:41] <apw> cjwatson, just uploaded linux and linux-lowlatency with the union mounts issues fixed, building now; ppc is being prepared
[16:42] <Laney> yay
[16:44] <xnox> \0/ apw
[17:01] <cjwatson> achiang: We don't rebuild the whole archive between release and UDS anyway - what you're seeing there is just syncs/merges of new versions of packages from Debian
[17:02] <cjwatson> achiang: Rebuilding the whole archive would be very expensive for mirrors and would likely lose us mirrors, so we try to avoid it
[17:02] <cjwatson> apw: Thanks
[17:03] <achiang> cjwatson: ack, thanks
[17:04] <trijntje> hi all. Where can I find a list of all packages that are visible in the default view of the software centre (ie, not the 'technical items')?
[17:05] <DaemonicApathy> http://packages.ubuntu.com ?
[17:16] <mitya57> trijntje, http://bazaar.launchpad.net/~ubuntu-core-dev/app-install-data-ubuntu/ubuntu/files/head:/menu-data/
[17:16] <mitya57> see all .desktop files there
[17:17] <ev> bdmurray, pitti: I've filed https://bugs.launchpad.net/apport/+bug/1079285 to come up with an approach for bucketing package installation failure errors
[17:20] <bdmurray> ev: there is this http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/apport/raring/view/head:/data/general-hooks/ubuntu.py#L103
[17:20] <ev> oh nice
[17:20] <ev> I had entirely missed that
[17:21] <hallyn> zul: is there anything you can do to push bug 882485 (needs-packaging for sanlock which is already in debian)
[17:21] <ev> bdmurray: do we get that untranslated?
[17:21] <hallyn> zul: of course i'm not denying it'll next need MIR :)
[17:22] <mitya57> hm, strings from PKG_MSGS *are* translated in dpkg
[17:23] <bdmurray> ev: I'm pretty sure only update-manager sets DPKG_UNTRANSLATED_MESSAGES
[17:24] <hankhendrix> hello, I'm wanting to edit the behaviour of "Changed Desktop Background" on the desktop context menu. Anyone know which package contains the source?
[17:25] <ev> hmm
[17:26] <ogra-cb_> hankhendrix, #ubuntu-desktop might be better suited for that question, i think it is gnome-settings-daemon though
[17:26] <hankhendrix> nice one cheers
[17:36] <ev> bdmurray: so we're definitely getting and bucketing them then: http://tinyurl.com/blsqa3a
[17:36] <ev> perhaps we should do something about those incredibly long bucket IDs/URLs though :)
[17:38] <bdmurray> probably
[17:51] <zul> hallyn: sure
[17:52] <zul> hallyn: sanlock is already in raring
[17:52] <hallyn> oh??  i thought i just checked
[17:53] <hallyn> zul: cool, thanks :)  "you work fast"
[17:53] <zul> hallyn:  efficeny is a hallmark
[17:59] <trijntje> mitya57: thanks, I'll check it out!
[18:23] <ScottK> bdrung: Would you please fix wxwidgets2.8 in raring so the quantal SRU can be accepted?
[18:25] <hankhendrix> does anyone know how to rebuild and test nautilus source?
[18:28] <slangasek> ogra-cb_, stgraber: is bug #1077598 something that's fixed in later casper?  There seems to be a second report of the same, bug #1079266
[19:15] <GunnarHj> SpamapS: Did you forget bug 875435? ;-)
[19:18] <SpamapS> GunnarHj: indeed I did ;)
[19:18] <SpamapS> GunnarHj: right after that I went on a tab-closing rampage and lost that one ;)
[19:20] <GunnarHj> SpamapS: Ok, no problem. Do you have time now?
[19:20] <SpamapS> GunnarHj: You need to re-do oneiric
[19:20] <SpamapS> GunnarHj: 1.20ubuntu5.1 was the version used for precise
[19:21] <SpamapS> GunnarHj: so you have to do a version lower than that. I suggest 1.20ubuntu5.0
[19:21] <GunnarHj> SpamapS: The release versions are the same as well.
[19:22] <SpamapS> GunnarHj: does not matter. The packages have to be lower version so that on upgrade the new packages are installed (toolchains, libraries, etc. etc)
[19:22] <GunnarHj> SpamapS: Ok, I'll change it then. Moving to another partition, so I 'll be away from here for a while.
[19:23] <SpamapS> GunnarHj: usually when doing a "same version but different distro" SRU you need to do something like 1.20ubuntu5.12.04.1 and 1.20ubuntu5.11.10.1
[19:24] <GunnarHj> SpamapS: Ok, I had no idea. Would you like me to change the Precise branch as well?
[19:29] <SpamapS> GunnarHj: no, precise is already accepted.
[19:46] <GunnarHj> SpamapS: Ok, I changed debian/changelog in the Oneiric branch for bug 875435.
[19:48] <GunnarHj> SpamapS: I.e. I changed https://code.launchpad.net/~gunnarhj/ubuntu/oneiric/im-switch/ibus-icon-in-menu_bar, not the one in the queue since I don't have upload rights.
[19:49] <RobOakes> Can someone point me in the direction of a tutorial that shows how to use Ubuntu Online Accounts Integration?
[19:49] <RobOakes> I'd really like to use it for an app that I am working on.
[19:49] <RobOakes> Would the examples in Gwibber be the best place to start? (I'm using Python.)
[19:50] <kenvandine> RobOakes, look at lp:friends (the gwibber-service rewrite)
[19:51] <kenvandine> RobOakes, and https://docs.google.com/a/canonical.com/document/d/1MVsDdwzff6LqQ6i3z-cSgg8dHjb5DaHMXFeWtIa6Cvo/edit
[19:52] <RobOakes> kenvandine: Thank you! This will be really helpful. I was looking for something like the docs last night and finally resigned myself to figuring things out from the examples shipped with Ubuntu.
[19:52] <RobOakes> Having good documentation speeds everything up.
[19:52] <kenvandine> indeed
[19:53] <kenvandine> also check out #accounts-sso
[19:53] <kenvandine> that is where the developers hang out
[19:53] <RobOakes> Awesome. I'll do that.
[21:01] <GunnarHj> SpamapS: Did you notice that I made the changelog change in https://code.launchpad.net/~gunnarhj/ubuntu/oneiric/im-switch/ibus-icon-in-menu_bar ?
[21:09] <SpamapS> GunnarHj: no I wasn't watching the branch. Do you need me to upload that to oneiric-proposed?
[21:24] <GunnarHj> SpamapS: Yes, I'd appreciate that since I don't have upload rights to the queue either.
[21:37] <SpamapS> GunnarHj: ok, uploaded, will approve shortly
[21:37] <GunnarHj> SpamapS: Thanks a bunch, Clint!
[21:54] <ogra-cb_> slangasek, hmpf, i thought that was fixed, yeah, its surely a duplicate
[21:59] <stgraber> ogra-cb_: both of those systems appear to be wubi installs on lucid doing an lts-to-lts upgrade to 12.04. My guess is that the fixes that landed in casper for that kind of usecase don't exactly cover this one.
[21:59] <stgraber> ogra-cb_: anyway, don't waste time on this, I'm already poking at it :)
[21:59] <ogra-cb_> ah, k
[22:00] <ogra-cb_> well, i dont have much to do until the nexus kernel is there and we have an arm builder again
[22:00] <ogra-cb_> but i didnt plan to look right now anyway
[22:13] <infinity> ogra-cb_: The nexus kernel is there.  Not sure about the progress on the livefs builder, though. :/
[22:57] <ogra-cb_> infinity, well, there was a cased panda overnighted to the DC, it should be up tomorrow
[22:57] <ogra-cb_> (which likely will require some cdimage changes, i doubt they'll keep the name)
[22:58] <ogra-cb_> infinity, and thanks for the kernel !!!!!!