[03:08] <selite_> Alright, since I care deeply about Ubuntu and know how to code. Can you please tell me how can I contribute?
[03:09] <RAOF> selite_: Any number of ways; what would you like to do?
[03:09] <selite_> RAOF: Write code.
[03:10] <robru> selite_, so, write some code then.
[03:10] <RAOF> Any particular type of code? You can usefully write code anywhere from the kernel to trivial apps.
[03:10] <plars> cjwatson: sounds good, I have a dr. appointment and a few other things, but if you can send me the details, we should be able to get it tested out early on
[03:10] <selite_> RAOF: my answer seems to be general but that is because I am lost, I am currently checking it Bazaar and I just don't understand how this thing works.
[03:11] <RAOF> selite_: So, Ubuntu is, in part, the aggregation of tens of thousands of individual projects, from the kernel to apps like Gwibber.
[03:11] <RAOF> selite_: Contributing to any one of those projects helps Ubuntu.
[03:12] <robru> selite_, so think of a program that you want to like, but has problems that bother you, and then go fix those.
[03:13] <selite_> robru: I download the source code from github, I fix a bug and then what do I with it?
[03:13] <selite_> robru: What if someone decides to put bugs intentionally how do you keep track of that?
[03:14] <RAOF> selite_: That depends on the project. If it's a project on github, generally what you'll do is fork, make your changes, and then submit a merge request.
[03:14] <RAOF> selite_: For Launchpad projects it's similar.
[03:14] <RAOF> selite_: For other projects (like the kernel, X, or mesa) the process is to create your patches and submit them to a mailing list.
[03:14] <RAOF> selite_: It depends on the project :)
[03:15] <selite_> RAOF: I understand. Do they keep a list of bugs that need to be fixed?
[03:15] <selite_> RAOF: For example for Gwibber.
[03:16] <RAOF> selite_: Generally, yes. You can check out the Ubuntu bugs on launchpad - https://launchpad.net/ubuntu/+source/gwibber/+bugs ; projects generally also have their own bug tracking. For example, github issues.
[03:20] <robru> RAOF, maybe not the greatest example because all those bugs are obsolete ;-)
[03:20] <robru> but yeah
[03:21] <robru> oh, he left. d'oh
[05:38] <pitti> mpt: I think I'll change apport to just not pass an UI object for crashes post-release
[06:33] <vibhav> cjwatson: What is the pkg-config "name" for libpipeline?
[06:36] <pitti> $ dpkg -L libpipeline-dev|grep pkgconfig
[06:36] <pitti> /usr/lib/x86_64-linux-gnu/pkgconfig/libpipeline.pc
[06:36] <pitti> vibhav: ^
[06:36] <vibhav> thanks
[06:37] <vibhav> pitti: but, shouldn't this be in PKG_CONFIG_PATH ?
[06:37] <pitti> it is
[06:37] <pitti> pkg-config knows about multiarch
[06:38] <vibhav> pitti: http://paste.ubuntu.com/5636218/
[06:38] <pitti> $ pkg-config --cflags --libs libpipeline
[06:38] <pitti>  -lpipeline
[06:38] <pitti> missing libpipeline-dev ?
[06:39] <vibhav> This is crazy, software center doesn't find libpipeline-dev
[06:39] <vibhav> while apt does
[06:40] <pitti> it's not an application
[06:40] <vibhav> yes, but SS does find -dev packages
[06:40] <vibhav> (at least here, it used to do that)
[06:48] <infinity> vibhav: I wouldn't generally recommend using SS for searching for libraries and dev things.  Most of the time, if it displays one, that's a bug, not a feature.
[06:48] <infinity> (IMO)
[06:49] <infinity> It's meant to be a top-level view of applications, with some semblance of user-friendliness which is, almost by design, developer-hostile.
[06:55] <vibhav> infinity: ah ok
[06:56] <infinity> vibhav: apt-cache search is probably a developer's best friend in this case.
[06:58] <sarnold> <3
[07:07] <zyga> good morning
[07:53] <leagris> Hello there,
[07:53] <leagris> I am testing 13.04 for some time and use google chrome from unstable chanel.
[07:54] <leagris> I know it is unstable and unsupported software. So I don't asks for any help here:)
[07:55] <leagris> Meaningwhile, I experience some huge bd2 (Ext4 journal update) with GoogleChrome
[07:56] <jamesh> mvo: ping?  Would you have time to answer a few questions about the software center?
[07:56] <leagris> So badly I came back to Firefox, because my spinning rust disk is so busy while Chrome is running, it become unresponsiv if it needs to fetch user profile datas for form filling and so on :)
[07:57] <leagris> I just like to reade your own experience with these unstable builds of Google Chrome here. Did you also notice an excess of IO with the bd2 process?
[07:59] <leagris> Google Chrome 27.0.1430.0 (Build officiel 186115) dev
[07:59] <leagris> WebKit	537.33 (@144673)
[07:59] <leagris> Mozilla/5.0 (X11; Linux x86_64)
[07:59] <mvo> jamesh: hi, sure
[08:00] <jamesh> We have a bunch of packages containing Unity scopes, and were wondering on the best way to make them show up together in a category on the software center
[08:01] <jamesh> Looking at the code, there seemed to be some stuff to scrape XB-Category fields from the package metadata, but this doesn't seem to be what is used for the majority of packages in the archive
[08:02] <mvo> jamesh: I'm talking with mhr3 about this right now
[08:02] <mvo> jamesh: in #ubuntu-desktop
[08:02]  * jamesh joins
[08:04] <leagris> Though, I am reluctant on updating an old bug about unexpected bd2 activity preventing laptop disk spin down and draining batteries. I use a desktop computer, and I identified Google Chrome as the source of this excessive bd2 activity.
[08:06] <leagris> oups, I meant jbd2
[08:07] <leagris> It could match this still opened old bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/607560
[08:10] <leagris> Launchpad is a so big load of bugs filled by clueless users like me. I praise you dev and maintainers unbelivable ability to pick any relevant information from it :P
[08:15] <dholbach> good morning
[08:16] <leagris> hello good morining dholbach
[08:16] <dholbach> hi leagris
[09:11] <pitti> vibhav: https://code.launchpad.net/~vibhavp/ubuntu/raring/libpipeline/add-atuopkgtest/+merge/154883 verified; bouncing to cjwatson as I guess he wants to keep this in sync and upload to Debian instead
[09:13] <vibhav> sure, thanks
[09:24] <mitya57> jamespage: re bug 1157421: I now have a working branch attached, but I don't yet know what to do with the linux-headers-generic dependency (which makes it build with 3.2 headers)
[09:25] <mitya57> (asked on #ubuntu-kernel now)
[09:26] <jamespage> mitya57, I'd be tempted to drop the dependency on headers; thats what openvswitch and iscsitarget do
[09:26] <mitya57> and also I wonder if I should add fix-vm-reserved.patch from raring to fix compilation with 3.7+
[09:27] <jamespage> mitya57, no - we just need the minimal fix for 3.5 support right now
[09:27] <tkamppeter> xnox, jodh, I have reported a bug on avahi, to apply a workaround for making CUPS to reconnect to avahi-daemon after a restart of avahi-daemon, bug 1158686. Can you apply it in Raring?
[09:28] <mitya57> jamespage: it doesn't depend on openvswitch or iscsitarget — or what do you mean?
[09:28] <jamespage> mitya57, both of those packages ship dkms packages; the dkms package don't depend on linux-headers
[09:29] <mitya57> ok, but dkms itself now also doesn't depend on headers...
[09:29] <jamespage> mitya57, yeah - but the ubuntu install process should install the correct headers for the right kernel by default
[09:30] <mitya57> fair enough :)
[09:30]  * mitya57 drops the dependency and files a MP
[09:31] <jamespage> mitya57, nice one!
[09:32] <mitya57> jamespage: should I leave "linux-headers-generic [i386 amd64] | linux-headers" in Suggests?
[09:32] <jamespage> mitya57, personally I would just drop them
[09:37] <seb128> cjwatson, hey, do you think you could add https://launchpadlibrarian.net/131228119/openssh_lp-952185_raring.patch to your review list? it's in the sponsoring queue but reflected as SRU for lightdm, but in fact has a patch for openssh
[09:40] <cjwatson> seb128: it *is* on my review list already
[09:40] <mitya57> jamespage: done, https://code.launchpad.net/~mitya57/ubuntu/precise/blktap-dkms/lp1157421/+merge/154892
[09:41] <cjwatson> but I need to think hard about it - even though it's a small patch I need to go and make sure that moving the env handling doesn't affect anything undesired within sshd
[09:41] <ogra_> hmm, seems like the rm for /current misses a -r in the new cdimage code :)
[09:41] <ogra_> (unlink() fails)
[09:43] <ogra_> oops, i thought i was in -release
[09:43] <seb128> cjwatson, ok, good, I will unsubscribe sponsors from the bug if that's fine with you (so we avoid having other people doing the review, or somebody just sponsoring without giving it too much thinking)
[09:43] <cjwatson> seb128: sure, somebody already said they'd done that yesterday ...
[09:43] <seb128> ok, done
[09:44] <cjwatson> ogra_: where are you seeing that?
[09:44] <cjwatson> oh, yeah, ok, build logs
[09:44] <ogra_> in the failed buildlogs
[09:44] <cjwatson> I'll sort that out, thanks
[09:44] <ogra_>  File "/srv/cdimage.ubuntu.com/bin/../lib/cdimage/osextras.py", line 53, in unlink_force
[09:44] <ogra_>     os.unlink(path)
[09:44] <ogra_> OSError: [Errno 21] Is a directory: '/srv/cdimage.ubuntu.com/www/full/ubuntu-server/precise/daily/current'
[09:44] <cjwatson> I only just got in, give me a minute to go through it all
[09:45] <ogra_> i didnt mean to be pushy .... just reported it as i found it when reading morning mail :)
[09:45] <cjwatson> aside from anything else there's the question of why that's a directory, since the new code isn't supposed to be active yet
[09:45] <ogra_> yeah
[09:45] <cjwatson> so need to do some background checking
[09:45] <vibhav> ogra_: For a moment, I thought the C unlink() wasnt working :D
[09:46] <ogra_> vibhav, well, not sure if cjwatson ported cdimage to C secretly over night :)
[09:46] <ogra_> looks like a python error though ;)
[09:47] <vibhav> ogra_: I mean unlink() in the daily builds :P
[09:47] <vibhav> I read it incorrectly
[09:47] <cjwatson> os.unlink is a very thin wrapper around libc unlink anyway
[09:48] <jamespage> mitya57, looking now
[09:49] <mitya57> jamespage: one more question for you: "the ubuntu install process should install the correct headers for the right kernel by default" — does that apply to Debian?
[09:49] <jamespage> mitya57, hmm - not sure
[09:49] <mitya57> (otherwise we should apply this in raring as a delta)
[09:51] <mitya57> zigo: maybe you know (^)? we are talking about dropping linux-headers dependency from blktap-dkms package you're maintaining :)
[09:51] <xnox> tkamppeter: updated the bug with more "upstart like" post-start. But you are correct that post-start does not run on restart avahi-daemon. I can't remember how to execute stuff on restart, let me check the cookbook again.
[09:53] <mitya57> zigo: btw you may also be interested in my support_kernel_3.4.patch
[10:02] <jamespage> mitya57, uploaded and subscribed ubuntu-sru to the bug report
[10:02] <jamespage> mitya57, thanks for fixing that up
[10:04] <mitya57> jamespage: thanks! maybe it'll make sense to do a raring upload dropping the dependency (otherwise it can be rejected)
[10:05] <jamespage> mitya57, I think that would make sense
[10:05] <mitya57> jamespage: should I do another MP?
[10:05] <jamespage> mitya57, that would be lovely!
[10:06] <xnox> tkamppeter: posted a task job which should reload cups whenever avahi-daemon is started or restarted.
[10:09] <mitya57> jamespage: https://code.launchpad.net/~mitya57/ubuntu/raring/blktap-dkms/no-headers-dependency/+merge/154897
[10:21] <cjwatson> ogra_: fixed
[10:26] <ogra_> cjwatson, great, thx
[10:27] <tkamppeter> xnox, looks great, I am testing now.
[10:30] <tkamppeter> xnox, on cold boot avahi-daemon starts before cups, so when the task gets triggered "reload cups" is executed with cups not yet running and so it exits with 1. Does this cause any problem? Should we surround the "reload cups" by "if status cups | grep start/running; then ...; fi"?
[10:30] <xnox> tkamppeter: it's fine, the task starts & fails, and live goes on.
[10:30] <xnox> s/live/life/
[10:31] <xnox> tkamppeter: the task stanza is special as each time this job is triggered a new unique (throwaway) instance is created and expected to exit soon.
[10:31] <zigo> mitya57: Why dropping the kernel header thing?
[10:31] <zigo> mitya57: If you drop that dependency, can the DKMS module build?
[10:31] <mitya57> zigo: in Ubuntu the right headers are always installed
[10:32] <zigo> mitya57: You mean, by default, you *always* have the headers?
[10:32] <zigo> Even with a raw system installed by debootstrap?
[10:33] <mitya57> jamespage: ^
[10:35] <zigo> mitya57: Could you please send requests to me via the Debian BTS ?
[10:35] <zigo> mitya57: Including your patch if possible.
[10:36] <zigo> blktap-dkms-2.0.93.patch ?
[10:36] <zigo> Is it that one?
[10:37] <mitya57> zigo: that was not a request, but a suggestion :)
[10:37] <mitya57> patch is https://bazaar.launchpad.net/~mitya57/ubuntu/precise/blktap-dkms/lp1157421/view/head:/debian/patches/support_kernel_3.4.patch
[10:38] <mitya57> (there's also another patch in raring that makes it work with 3.7/3.8)
[10:38] <zigo> mitya57: I don't mind request or suggestion, I appreciate both! :)
[10:38] <zigo> Well, I can apply on one of them, no?
[10:39]  * xnox ponders who or what creates ~/.cache/archive-cache/ which is filled with 11GB of .debs I have on a local mirror anyway....
[10:39] <mitya57> zigo: as experimental has 3.8, you may want to apply both
[10:40] <mitya57> (obviously, that's for jessie, not for wheezy)
[10:41] <tkamppeter> xnox, I have tested it and it works on stop/start, restart, crash/respawn (simulated by "killall -9 avahi-daemon"), reboot.
[10:41] <xnox> tkamppeter: cool thanks. uploading then.
[10:41] <mpt> ev, what revision is errors.ubuntu.com running?
[10:42] <ev> mpt: 300, by the looks of it.
[10:44] <cjwatson> ogra_: OK, I worked out why those were directories as well - it was due to stale builds for architectures that we no longer build for by default.  I've removed those images and "current" should automatically collapse itself back to a symlink at the next build.
[10:45] <ogra_> ok
[10:45] <ogra_> which arches ? armel and so on ?
[10:45] <cjwatson> powerpc, and amd64+mac for server
[10:45] <ogra_> ah
[10:46] <cjwatson> now, metalinks still aren't working right
[10:46]  * cjwatson looks at that next
[10:46] <tkamppeter> xnox, so the new file will be in avahi?
[10:46] <ogra_> do we still need them ?
[10:47] <mitya57> zigo: looks like in Debian dkms takes care about headers itself, so the explicit dependency is not needed (take a look at openvswitch-datapath-dkms for example)
[10:47] <ev> mpt: I'd like to get tip deployed, but I'm trying to fix a few things that are going to drive people mad, like how changing the "users of" box doesn't update the table.
[10:47]  * ogra_ would think we might put wubi down at some point soon
[10:48] <ev> mpt: ideally I'd like to fix the pinstripe and the transition of the milestones when you select a different release, but there are far more important things to deal with. Might be one for the weekend.
[10:48] <zigo> mitya57: Let me try to build it in a cowbuilder then.
[10:49] <cjwatson> metalink> oh, this is because I'm an idiot
[10:49] <cjwatson> ogra_: not a justification for obvious code bugs :)
[10:49] <cjwatson> like a missing call to main()
[10:49] <ogra_> oops :)
[10:49] <mitya57> to be precise, dkms *recommends* headers
[10:50] <zigo> mitya57: I mean piuparts ...
[10:50] <zigo> I'll try piuparts test in SID.
[10:50]  * mitya57 will have to go in 10 minutes
[10:50] <ev> mpt: for what it's worth, https://rt.admin.canonical.com//Ticket/Display.html?id=60205 is blocked by the pile of stuff in front of it on the webops queue: https://portal.admin.canonical.com/ruins?team=losa
[10:51] <mpt> ev, I'm not chomping at any bit, I was just wondering how to evaluate a bug comment of the form "This bug might be solved in r360"
[10:51] <seb128> xnox, do you have an opinion on https://code.launchpad.net/~fehwalker/ubuntu/raring/ureadahead/fix-969926/+merge/153429? I think you wrote on the list recently you were happy to sponsor ureadhead fixes, want to look at this one? ;-)
[10:52] <ev> mpt: there's always http://poppy-dev.local
[10:52] <mpt> Oh. Right.
[10:52] <ev> :)
[10:53] <cjwatson> OK, any broken metalinks should sort themselves out over the next day or two now; I regenerated the most important ones
[10:54] <zigo> mitya57: The kernel header stuff are pulled by dkms Recommends:
[10:54] <xnox> zigo: not on ubuntu.
[10:54] <zigo> mitya57: So as much as I understand it, the linux-header dependency is really needed.
[10:55] <zigo> xnox: So, in Ubuntu, you have a Depends:?
[10:55] <xnox> zigo: no. externally managed/installed. kernel itself depends on headers.
[10:55] <mitya57> in Ubuntu we don't even have Recommends
[10:55] <xnox> zigo: you should depend on the headers in Debian, though.
[10:56] <zigo> Ok, then I believe I have to do a conditional Depends: then.
[10:56] <xnox> but in ubuntu we do not want it.
[10:56] <zigo> (using the substvar trick and dpkg-vendor...)
[10:56] <mitya57> xnox: so will that "external management" work in "a raw system installed by debootstrap"?
[10:56] <zigo> I'm doing that now then.
[10:57] <xnox> zigo: basically we do not have a single top-level headers package and it gets renamed, hence the dependency is in the kernel flavour. Not sure what you mean by a raw system installed by debootstrap - if kernel is installed on ubuntu (even via debootstrap), headers package will be pulled in.
[10:58] <mitya57> xnox: thanks for clarifying that!
[10:58] <xnox> if there is no kernel installed, headers will not be pulled in. And well I am not sure there is a use-case for dkms, if kernel is not installed.
[10:58] <zigo> xnox: Well, you do not really have to install a kernel to have a working system!
[10:58] <vibhav> win 6
[10:58] <vibhav> soory
[10:58] <vibhav> sorry, even
[10:58] <zigo> xnox: I run hundreds of virtual machines at GPLHost without the kernel package installed.
[10:59] <xnox> zigo: sure, but dkms will not work without a kernel package, now will it? =) Oh.... hmm... I see....
[10:59] <zigo> But well, anyway, I'm doing what I wrote above to make you guys happy! :)
[10:59] <tkamppeter> xnox, thank you very much for your help.
[10:59] <xnox> tkamppeter: no problem.
[11:00] <ev> mpt: I decided to make the milestone labels noninteractive last night. Being able to select which lines are shown on the graph independent of the "Showing error reports from" box state, which also determines what lines are shown, seemed confusing (plus the code was getting complex).
[11:00] <mpt> ev, they were interactive before??
[11:00] <ev> briefly
[11:00] <ev> like so: http://nvd3.org/
[11:00] <mitya57> zigo: if you are going to add a conditional depends, that will be very good (and probably will allow us to drop our delta at some point)
[11:01] <ev> (click on stream2)
[11:01] <zigo> mitya57: Yes, I'm doing that right now.
[11:01] <mitya57> thanks!
[11:01] <cjwatson> eh, packages generally can't ever sensibly depend on kernel headers
[11:02] <cjwatson> because they don't know which kernel flavour is installed
[11:02] <mpt> ev, love the stereotypical open-source whimpering on that page: "This project is an attempt to build..."
[11:02] <cjwatson> this is why we have to have something like dkms to do it at run-time instead ...
[11:02] <ev> mpt: lol
[11:03]  * mitya57 will be back in 1.5 hours
[11:04] <ev> d3 at least breaks from some of the other stereotypical open source stuff, like giving you lots of nobs and switches to write bad code. (https://groups.google.com/forum/?fromgroups=#!topic/d3-js/mEjem7IPshY)
[11:11] <zigo> http://anonscm.debian.org/gitweb/?p=pkg-xen/blktap-dkms.git;a=commitdiff;h=ab9a0d189cc196a2a09e35127a8570950d2c419c <--- As requested.
[11:11] <zigo> (or suggested ... :) )
[11:13] <zigo> So which patch should I apply then?
[11:16] <leagris> Something wierd just happened. I had apport crash popup soon after login in 13.04, then it said the problem wals already reported here https://bugs.launchpad.net/bugs/1121896
[11:16] <cjwatson> zigo: well, surely that dependency is wrong in Debian too.  What if somebody has, say, linux-image-amd64 installed rather than linux-image-generic?
[11:16] <cjwatson> s/installed/running/
[11:16] <leagris> Unfortunately, well as you can see, this page/bug does not exist at Launchpad ;D
[11:17] <leagris> So, It failed to tell what crashed and pointed to an invalid bug
[11:17] <cjwatson> It exists but it's private
[11:17] <cjwatson> However I don't know enough about indicator-sync to know whether I can safely mark it public (i.e. whether it contains user data)
[11:18] <cjwatson> Perhaps somebody else does
[11:19] <leagris> Ah yes, funny situation :) got it mentioned in here https://bugs.launchpad.net/ubuntu/+source/indicator-sync/+bug/1130062
[11:20] <seb128> cjwatson, leagris: I market it public, the indicator can "leak" filenames, nothing else
[11:20] <seb128> but that's not even the case in that report
[11:21] <pitti> darkxst: I have a proposed general hook for you in bug 1158119
[11:21] <leagris> thank you seb128 and no worries, I know someone will look at it before release :)
[11:22] <darkxst> pitti, thanks, let me test
[11:23] <leagris> Are there some maintainers of compiz and or accessibility team here?
[11:25] <leagris> I'd like to share my concern on the maybe endangered future of compiz within Ubuntu. I am visually impaiared and the eZoom plugin is my most efficient beloved screen magnifier for everydays since years. Gnome Orca and other tools are pale and inappropriate replacementss I would not want to fallback to.
[11:25] <didrocks> leagris: TheMuso is the accessibility specialist, but he lives in australia, so you maybe want to chat with him
[11:27] <tkamppeter> xnox, I have assigned bug 1158686 to you, as you told that you are uploading avahi with the new file.
[11:27] <leagris> I already avoided Unity for its poor experience with compiz eZoom (launch bar not magnified and not following zoomed area). I really feel left behind more and more. Not funny and no trolling here.
[11:27] <xnox> tkamppeter: sure. just fighting with my new desktop to make it build packages (homedir rsync still in progress)
[11:29] <darkxst> pitti, will that still run the normal package hooks as well?
[11:29] <pitti> darkxst: yes
[11:31] <darkxst> ok, looks good then
[11:32] <leagris> I'd pay for having compiz eZom maintained. Not that much in regard to the work and responsabilities, but at least I sure would drop $600 as it is the price of a ZoomText licence for the Microsoft OS :)
[11:35] <leagris> And I am reluctant to drop money to a broad organisation, be it non-profit as it may be significantly diluted before it reach the compiz eZoom package maintener for Ubuntu.
[11:36] <zigo> cjwatson: linux-headers-amd64 has a Provides: linux-headers
[11:36] <zigo> So the dependency is satisfied.
[11:36] <didrocks> leagris: again, as told previously, you should talk with TheMuso when he's online
[11:37] <leagris> didrocks: took a note to poke TheMuso wile in the proper timezone thanks
[11:37] <didrocks> yw
[11:54] <cjwatson> zigo: It's satisfied, but there's no reason apt will pick the right one; as a result the user will often have to intervene anyway
[11:55] <cjwatson> zigo: A dependency on plain linux-headers would make sense, perhaps - but there's no reason, either in Debian or Ubuntu, why the package has any justification for claiming it knows what the preferred alternative is
[11:55] <cjwatson> So I don't think it is right to specify a preferred alternative
[11:56] <cjwatson> (I don't know the history of this bug/patch/whatever so I don't know if this started out with the dependency being actively inconvenient in Ubuntu)
[11:56] <zigo> cjwatson: With the patch from upstream it fails to build the kernel module for 3.8
[11:56] <zigo> http://paste.debian.net/243647/
[11:57] <zigo> It did work for 3.2.0-* though.
[11:57] <cjwatson> That has nothing to do with dependencies though
[11:57] <zigo> Ah no.
[11:57] <zigo> Sorry, forgot to push / pull it seems.
[11:57] <zigo> cjwatson: Right, that's another problem! :)
[12:06] <zigo> Uploaded.
[12:42] <mitya57> zigo: hi again :)
[12:42] <mitya57> you need either *both* patches or none of them
[12:42] <zigo> mitya57: Both being which ones?
[12:43] <zigo> I applied only the one from upstream, for linux 3.7+, and it worked, always ...
[12:43] <zigo> For me, it seems fine.
[12:43] <mitya57> what you applied doesn't make sense without https://bazaar.launchpad.net/~mitya57/ubuntu/precise/blktap-dkms/lp1157421/view/head:/debian/patches/support_kernel_3.4.patch
[12:43] <mitya57> worked? let me recheck...
[12:44] <hallyn> wait - does uefi not work with virtio?
[12:45] <zigo> Yup, it seems it built with 3.2 and 3.8 kernels.
[12:45] <zigo> I didn't try with 3.4 though (as this isn't in Debian).
[12:55] <mitya57_> zigo: I have no clue why it works for you without the "first" patch, but if it works, let's leave it as is
[12:55] <mitya57_> fwiw, my patch was based on https://github.com/mcclurmc/blktap-dkms/commit/d33302b91d
[13:17] <hallyn> cjwatson: trying 12.0.4.2 desktop install again.  last syslog line is "purging configuration files for user-setup", then I see defunct plugininstall.p
[13:18] <hallyn> well, but no, i guess dpkg is still running.  it's not really hung.
[13:19] <hallyn> wonder why it's sooooo sloooooooooow
[13:20] <GridCube> hi, its allow-guest removed from the default lightdm.conf?
[13:33] <ogra_> distro packages shouldnt use" !#/usr/bin/env python", right ? or do i misremember
[13:34] <ogra_> ah, there was some confusion of autopilot setting it to env ... seems thats not ture
[13:35] <mitya57> ogra_: they can, but /usr/bin/python[3] is better, see http://lists.debian.org/debian-python/2012/04/msg00104.html
[13:35] <ogra_> yeah
[13:35] <ogra_> thats what i remembered
[13:36] <ogra_> just wanted to make sure i didnt miss another policy change :)
[13:36] <mitya57> You shouldn't care if you use dh_python2 (3)
[13:36] <ogra_> yup
[13:42] <hallyn> stgraber: all right, so 12.04.2 in qemu using ovmf and ide drives seems to be installed in secure mode.  Now - this appears to be (in contrast to TPM) completely useless to me.  So what exactly was it that you wanted to have be configurable?
[13:43] <hallyn> pstore?
[13:44] <stgraber> hallyn: so what we should have configurable is the various secureboot bits. Basically having the option to preseed the VM with the standard Windows CA or have it boot in setup mode (without any key)
[13:45] <hallyn> ruh roh - fails to boot on second boot
[13:46] <hallyn> stgraber: ok, i think i understand - thx
[14:27] <bdrung> bryce: i like to help fixing bug #1094499. i can reproduce the crash and could help collecting the needed information. i just need to know what to do.
[14:50] <ev> mpt: why require the tilde character in the package subscription field on errors.u.c? It's always going to be a team or user, so isn't the tilde superfluous?
[14:50] <mpt> ev, to distinguish it from a package name
[14:51] <ev> mpt: you think people will type the name of a package into a box preceded by "packages subscribed to by"?
[14:53] <mpt> Oh, right. Why did I do that?
[14:53]  * mpt rereads
[14:55] <Sarvatt> bdrung, bryce: looks like http://lists.mplayerhq.hu/pipermail/dvdnav-discuss/2013-March/001896.html is the fix to that
[14:56] <mpt> ev, ah, it's because I specified a combo box, where the currently selected menu item wouldn't be visible
[14:56] <mpt> whereas now it's a menu followed in that case by a text field
[14:56] <Sarvatt> (possibly)
[14:56] <ev> ahh, in that context it makes sense to me
[14:56] <mpt> ev, in that case, yeah, drop the tilde
[14:56] <ev> woo
[14:56] <ev> bdmurray: ^
[14:58] <mpt> ev, <http://www.quickmeme.com/meme/3thdxg/>, but in the meantime, I'll edit to describe the text field
[14:59] <ev> lol
[14:59] <bdrung> Sarvatt: let me try that patch
[15:01] <bdrung> Sarvatt: nope, it does not help
[15:06] <stokachu> barry: im using this http://paste.ubuntu.com/5637189/ for python dict with named attributes on 2.7 and was curious if this was a decent approach or if you know a better way
[15:06] <cjwatson> stokachu: Have you tried collections.namedtuple?
[15:07] <stokachu> cjwatson: i looked at that but was turned off since they were immutable
[15:07] <cjwatson> true
[15:07] <stokachu> i also saw recordtype on pypi which is a mutable named tuple of sorts
[15:07] <cjwatson> having lots of explicit setattrs seems dangerous; not sure why you wouldn't just implement __getattr__ instead
[15:08] <mpt> ev, https://wiki.ubuntu.com/ErrorTracker?action=diff&rev2=152&rev1=151
[15:08] <cjwatson> I mean it seems kind of like an invitation for things to get out of sync
[15:08] <stokachu> cjwatson: hmm good point
[15:08] <ev> thanks
[15:08] <cjwatson> the point of that sort of seems to be to constrain the set of field names at __init__ time
[15:09] <cjwatson> I think if I wanted to do that I might have just stored the set of keys somewhere and consulted it in __getattr__ instead
[15:09] <cjwatson> but whatever :)
[15:09] <stokachu> lol, i also found this routine that does a mutable named tuple as well http://paste.ubuntu.com/5637204/
[15:09] <stokachu> but it won't handle nested dicts
[15:10] <stokachu> which i guess really isn't a problem
[15:15] <barry> stokachu: hey.  yeah, it's kind of a shame you have to roll your own mutable named tuples
[15:16] <stokachu> barry: i saw python 3.3 has something like a simplenamedtuple or something
[15:17] <barry> stokachu: afaict, not in the collections module
[15:18] <barry> doesn't ring a bell
[15:18] <stokachu> ok
[15:20] <smartboyhw> slangasek, ping
[15:23] <ev> jodh: \o/ well done
[15:24] <jodh> ev: ta :)
[15:27] <slangasek> smartboyhw: hello
[15:27] <smartboyhw> slangasek, private message?
[15:28] <slangasek> smartboyhw: sure
[16:21] <chiluk> mvo in regards to pad.lv/1087543  Can we get that SRU'd into precise as well?
[16:22] <chiluk> I can create the debdiff if you'd like, but I wanted to find out what you'd want first *(if anything).
[16:22] <infinity> Well, and if what he committed upstream matches the patch.
[16:22] <chiluk> deb-diff bzr branch?...
[16:22] <chiluk> right.
[16:35] <roadmr> Hey folks! question. We're past feature freeze, I have upload rights for a package, and I need to upload a new version that contains only bugfixes. Do I upload it as usual or is additional process needed to e.g. get it reviewed/approved by someone? (e.g. release team)
[16:49] <slangasek> roadmr: upload as usual
[16:49] <slangasek> roadmr: the feature freeze exception process is for things that are exceptions to the freeze on *features*, bugfixes require no extra paperwork :)
[16:50] <roadmr> slangasek: awesome, thanks!
[16:58] <xnox> roadmr: also we are in UI freeze as well, so if your package/app is visible in screenshots / documentations / translations please get a UIFe for it.
[16:59] <slangasek> ... if you're changing the UI
[17:02] <roadmr> xnox: thanks for the reminder :) Just checked, no UI or string changes
[17:05] <mvo> chiluk: I think we can SRU it if it got serious testing from you guys
[17:06] <mvo> chiluk: iirc this is already in debian experimental, I'm not 100% certain about the freeze status in raring, but I think we could merge some of the recent fixes in apt should all be pretty safe for raring
[17:07] <chiluk> mvo, testing does become the issue.
[17:07] <chiluk> and that is my concern as well.
[17:08] <mvo> chiluk: I see, what can we do? provide a testing PPA for you to make the testing eas{y,ier} ?
[17:10] <chiluk> Yeah I guess a precise PPA wouldn't be a bad idea.
[17:11] <chiluk> let me ask this how do you feel about the risk of this change.
[17:11] <mvo> chiluk: I think the risk is low but non-zero
[17:12] <chiluk> mvo at first glance it looks like a quick change
[17:12] <mvo> chiluk:  I can create a testing PPA on monday - would you remind reminding me again then?
[17:12] <chiluk> yeah sure.. I can do it as well.
[17:12] <mvo> chiluk: sure, either way is fine
[17:12] <chiluk> also where is the development branch for apt.
[17:12] <chiluk> is it lp:ubuntu/apt ?
[17:13] <mvo> chiluk: the ubuntu branch is lp:~ubuntu-core-dev/apt/ubuntu
[17:13] <chiluk> mvo glad I asked I wouldn't have guessed that.
[17:13] <mvo> chiluk: the upstream one is on bzr.debian.net/bzr/apt/debian-{wheezy,sid,experimental2}
[17:14] <mvo> chiluk: :) its in the apt-cache showsrc apt header in Vcs-bzr
[17:16] <chiluk> thanks mvo, I'm still new to source control in this debiany world..
[17:16] <mvo> chiluk: np
[17:16] <mvo> chiluk: and thanks for working on this! just keep me updated on the PPA thing, I will go and have dinner now :)
[17:16]  * mvo waves
[17:17] <chiluk> thanks mvo
[17:18] <mvo> yw
[17:54] <bdmurray> slangasek: so the other day was a bug day for ubuntu-release-upgrader and some bug triage was done and I'm reviewing most of it.  There is one bug 1044144 re: 'mixed non-coninstallable and coinstallable package instances present' which sounds familiar.
[17:56] <infinity> bdmurray: I think we have a hackish workaround in dpkg for that now.
[17:57] <infinity> bdmurray: https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1015567
[17:58] <infinity> bdmurray: Your bug is probably a dupe of that, and long ago fixed.
[17:58] <infinity> Well, "fixed".
[17:58] <bdmurray> infinity: thanks I knew it sounded familiar
[17:58] <infinity> We still don't have a strategy to upgrade the database sanely, IIRC, but the symptom should be gone.
[18:00] <bdmurray> right the upgrade looks like bug 1057367
[18:00] <bdmurray> which probably should be targetted to some future release
[18:02] <infinity> Oh look, there's a new dpkg in unstable for me to merge.
[18:03] <ScottK> What could go wrong?
[18:03] <infinity> It's all just bugfixed and translations, it was aimed at a freeze unblock.
[18:03] <infinity> bugfixes, even.
[18:04] <infinity> In fact, MOM did a clean merge.  I wonder if I should be suspicious of that. :P
[19:36] <bdmurray> slangasek, infinity: I've also seen a couple of bugs where packages eem to unpacked and then later when trying to set them up there is an error regarding them not being installed
[19:36] <bdmurray> bug 1068996 is an example
[19:37] <cjwatson> I think you've mis-explained that
[19:37]  * cjwatson follows up
[19:39] <cjwatson> (done)
[19:40] <cjwatson> heh, that terminology is particularly confusing in that example.  In the first case "installed" really means "configured", and in the second case it really means "unpacked", I think.
[19:41] <bdmurray> cjwatson: could you elaborate a bit?
[19:42] <cjwatson> I followed up in the bug - do you mean elaborate further on that?
[19:42] <bdmurray> "In the first case 'installed' really means 'configured'".  Which first case?
[19:43] <cjwatson> You quote a fragment of apt-term.log with two occurrences of "installed"
[19:43] <cjwatson> wait.  sigh.  I'm obviously confused and should finish for the week.
[19:44] <ironhalik> Hello, I'm a newbie and I wanted to submit a patch. I'm just not sure wether I should submit it to the gnome project or Ubuntu (it regards gnome-system-monitor) to get the best chance of seeing it in 13.04
[19:45] <cjwatson> bdmurray: followed up again in a slightly less confusing way, sorry
[19:46] <bdmurray> cjwatson: ah, thanks
[19:47] <bdmurray> ironhalik: given where we are in the development of 13.04 I would say both
[20:46] <bdmurray> infinity: is that previous bug really bug 1062503?
[20:46] <bdmurray> 'do not do lock-step configuration for a M-A:same package if it isn't unpacked yet in SmartConfigure and do not unpack a M-A:same package again in SmartUnPack if we have already configured it
[20:48] <infinity> bdmurray: It *might* relate.  It's hard to say from just the log why the :i386 one hadn't been unpacked.
[20:48] <infinity> bdmurray: It might not have been on the install list at all, which would be a resolver failure, or it might have been on the list, but not unpacked at the right time.
[23:47] <geomyidae> Can I get help with these bugs: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1080701 https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1120938
[23:47] <geomyidae> I think they're the same bug, kind of a bigish deal imo