[00:50] <TheMuso> 1/c
[01:05] <psusi> I'm getting unexpected change events on a partition device according to udevadm monitor, is there a way to get more information on why the kernel is emitting the event?
[01:05] <psusi> I thought a change event on a disk meant the partition table changed... why on earth with a partition emit a change event?
[07:45] <\sh> moins
[07:47] <dholbach> Good morning!
[07:48] <\sh> hey dholbach *hatschew*
[07:49] <dholbach> hi \sh
[07:49] <dholbach> Gute Besserung! :)
[07:49] <\sh> dholbach: danke :)
[07:49] <\sh> three days in bed...:(
[07:49] <dholbach> ugh :(
[07:50] <\sh> dholbach: but regarding the weather outside, I think it's normal to have a cold these days
[07:50] <dholbach> I'm not a big friend of the weather either :)
[07:51] <bilalakhtar> dholbach: in orlando?
[07:51] <\sh> it's just too cold for autum...
[07:52] <dholbach> bilalakhtar, Berlin, Germany
[07:52] <bilalakhtar> dholbach: ah, I thought you reached for the UDS :)
[07:52] <dholbach> Orlando will be different :)
[07:52] <dholbach> tomorrow afternoon I'll be there
[07:52] <bilalakhtar> cool
[08:01] <pitti> Good morning
[08:02] <pitti> tkamppeter_: no, was already off; you can rename blueprints, yes
[08:02] <pitti> ogra_ac: hello
[08:03] <pitti> slangasek: p-common> thanks! the trunk is in ~pitti, because I upload those to Debian and sync over; but yes, the Ubuntu stable ones should be reowned; I'll do that on the next SRU, when I can update Vcs-Bzr
[08:04] <pitti> tkamppeter_: ah, indeed -- cups-ppdc is in universe
[08:04] <pitti> tkamppeter_: seems we need to update cups again to move the files to cups-common, sorry
[08:54] <pitti> apw: good morning! do you know who uploaded linux-linaro? It needs to be reuploaded with -v to include previous changelogs
[08:59] <apw> pitti, normally that is rtg
[08:59] <pitti> apw: thanks
[08:59] <apw> pitti, if you know the -v you want i might be able to sort it out
[09:00] <pitti> -v2.6.35-1006.12 (maverick final)
[09:00] <apw> pitti, and what version did he actually upload?
[09:01] <pitti> apw: there are two uploads in the unapproved queue, so in theory they could just be merged into one rev; but I guess that'd juggle git too much
[09:01] <pitti> apw: latest is 2.6.35-1008.15
[09:01] <pitti> in unapproved
[09:01] <pitti> .15 and .14 are in the queue, .13 is in -proposed, but untested
[09:01] <pitti> so the .15 upload needs to cover all three
[09:01] <pitti> cover -> in .changes
[09:01] <apw> got ya
[09:02] <pitti> apw: cool, thanks; rejecting the current two
[09:09] <pitti> jdstrand: can you please update the lucid tasks for the apparmor SRU? many are missing, some are already marked as "fix released" (which sounds wrong?), and some are "won't fix" (contradiction?)
[09:12] <pitti> jdstrand: also, the changelog points out that this needs adjustment of third-party profiles in some cases; that makes me nervous
[09:12] <apw> pitti, ok just uploaded, should be in the queue shortly
[09:13] <pitti> apw: thanks
[09:13] <apw> pitti, do shout if its not right
[09:14] <ajmitch> Rush
[09:14] <ajmitch> hm
[09:22] <pitti> apw: hm, nothign in the queue yet
[09:23] <apw> pitti, let me check
[09:26] <apw> pitti, ahh a permissions issue, am working on getting it resolved
[09:46] <tkamppeter_> pitti, hi
[09:57] <pitti> hi tkamppeter_
[09:58] <tkamppeter> pitti, it is about the CUPS SRU. Can one not simply move cups-ppdc to main?
[10:00] <pitti> tkamppeter: we can't retroactively fix maverick final; we can technically move it in maverick-updates, but not sure whether that'd break anything else; cjwatson, WDYT?
[10:02] <cjwatson> pitti: that would be OK
[10:03] <cjwatson> jibel: re your comment 19 on bug 664645 - please see slangasek's comment 5 on the same bug for why it was Fix Released rather than Fix Committed
[10:04] <pitti> tkamppeter: ok, moved to main; we missed the publisher by a minute, so hplip build can be retried in two hours
[10:04] <jibel> cjwatson, oh right. Thank you.
[10:04] <tkamppeter> pitti, thanks.
[10:07] <pitti> apw: hm, still nothing in queue - forgot to kill the .upload file or so?
[10:19] <dholbach> geser, it should be fixed now
[10:20] <geser> thanks
[10:24] <apw> pitti, it seems it just took a long time, its there now
[10:32] <bilalakhtar> bdrung: Any news on that audacious maintainance thing?
[10:37] <wgrant> Hm, this cups thing forces a "partial upgrade" on everyone :/
[10:37] <bilalakhtar> wgrant: Not for me
[10:37] <bilalakhtar> wgrant: You mean the recent cups SRU?
[10:37] <wgrant> Oh.
[10:38] <wgrant> That may actually be the resolver breaking on something else, i suppose.
[10:38] <wgrant> But cups wasn't checked for upgrade by default.
[10:38] <wgrant> Maybe the other failures made it angry.
[10:40] <Ian_Corne> Is this the correct place to "complain" about a lacking kernel update?
[10:44] <bilalakhtar> Ian_Corne: go ahead, we will suggest the proper place then
[10:45] <bilalakhtar> Ian_Corne: though #ubuntu-kernel
[10:45] <bilalakhtar> would be better
[10:49] <ogra_ac> pitti, all sorted now, there was a bug in my postinst in alsa-utils that caused a bug flood, slangasek accepted the fix quickly though
[10:59] <tkamppeter> wgrant, bilalakhtar: The problem of the CUPS SRU was that a new dependency on a package in Universe was added. If a user has no Universe activated (or if you are on the buildds) CUPS fails to install/update.
[10:59] <bilalakhtar> oh! But why was such a change made after release?
[11:00] <tkamppeter> wgrant, bilalakhtar, this is fixed now (by moving the package cups-ppdc to main) and the fix will appear in around one hour.
[11:00] <bilalakhtar> tkamppeter: yes, I just discovered the flaw by apt-cache searching
[11:02] <tkamppeter> bilalakhtar, the cups-ppdc contains some files which the main cups package needs to build the PPDs for the drivers which CUPS ships. These drivers are very rarely used and most developers and ddevelopment version users have Universe activated, so the bug was seen only after release.
[11:02] <bilalakhtar> aha!
[11:02] <bilalakhtar> yes, I got to the bug report
[11:03] <bilalakhtar> bug #485383
[11:04] <tkamppeter> bilalakhtar, and these label printers are only supported by the drivers which come with CUPS. For all other printers there are more sophisticated drivers like HPLIP or Gutenprint.
[11:04] <bilalakhtar> yup
[11:05] <bilalakhtar> Thanks tkamppeter for the fix
[11:13] <Ian_Corne> thanks bilalakhtar I reported there
[12:28] <akgraner> Hey all I wanted to share with you something that Associate Publisher, Linux New Media posted on Facebook this morning praising the Ubuntu Developers (its a couple lines sorry if I am flooding you all)
[12:29] <akgraner> Rikki Kite (via Facebook) "I would like to take this moment to thank the Ubuntu developers -- U Rock. I didn't bother reading the instructions for my new HP printer/copier/faxer or running the Windows/Mac 'starter CD'. I just plugged her in, Ubuntu searched for the drivers, and away she prints! Yay Ubuntu! Yay for not having to read the stinking printer manual!"
[12:30] <pitti> tkamppeter: ^
[12:30] <pitti> *applauds*
[12:30]  * nigelb sends hugs to Desktop Team
[12:34] <ogra_ac> wow, tkamppeter, congrats !
[12:45] <TheMuso> ogra_ac: The only annoying thing about the error with alsa-utils, is that it shows how many people run proposed when they probably shouldn't/don't need to.
[12:45] <ogra_ac> TheMuso, yeah, i was a bit shocked about the flood
[12:46] <ogra_ac> but its all fine now, sorry for the bugmail spam
[12:46] <TheMuso> ogra_ac: Its ok, I am m more shocked at users running proposed, as above.
[12:46] <ogra_ac> yeah
[12:51] <ScottK> Last I looked, the way it's described in the GUI for adding repositories isn't nearly scary enough.
[12:53] <ogra_ac> TheMuso, btw, do you have an idea why we dont create any debvices in /dev/snd anymore ? is it a deliberate decision to not be compatible with alsa only setups anymore ?
[12:54] <tkamppeter> Thanks, setting up supported printers with Ubuntu is MUCH faster than under Windows, and no reboots at all.
[12:55] <TheMuso> ScottK: I am enclined to agree.
[12:55] <TheMuso> ogra_ac: Udev takes care of all /dev/snd stuff.
[12:56] <ogra_ac> TheMuso, well, i have some HW where it doesnt
[12:56] <ogra_ac> i need to create a rule in /etc/udev/rules.d to have devices under /dev/snd to make it work at all
[12:57] <ogra_ac> (its a non std. kernel on very exotic HW)
[12:59] <TheMuso> ogra_ac: Right, does support exist for the hardware upstrea? If so, the udev glue should probably go somewhere upstream as well.
[13:00] <rneese_> morning
[13:01] <ogra_ac> TheMuso, no support upstream yet, its an arm tegra2 (the toshiba ac100), there is only a 2.6.29 kernel for it with ubuntu config, the sound device needs special initialization by a proprietary nvidia tool initi
[13:01] <rneese_> anyone here good with how remaster a cd and make it install extra pkgs
[13:01] <TheMuso> ogra_ac: Right.
[13:02] <rneese_> looking to have a custom cd for installing a pbx setup
[13:02] <rneese_> I have a script that does it now
[13:02] <ogra_ac> TheMuso, if i dont divert pulse on that HW (without initializing the sound device) pulse goes into an endless probe loop and consumes 100% CPU
[13:02] <rneese_> but we want a iso to do all the work
[13:02] <ogra_ac> TheMuso, so i tried to use a soundblaster play (USB soundcard) which i can only make work with the udev hack
[13:04] <ogra_ac> TheMuso, the rules are trivial and just make sure sound devices end up in /dev/snd instead of /dev http://paste.ubuntu.com/518017/
[13:04] <rneese_> https://help.ubuntu.com/community/InstallCDCustomization is what I am reading now
[13:08] <ScottK> barry: I'm unable to replicate the python2.7 build failure on powerpc (builds fine on the hardware I have access too).  I was thinking it might make sense to try not doing the profiled build on powerpc as that's solved similar issues in the past.  Unfortunately I'd have to just heave it at the buildd's and see.  Thoughts?
[13:09] <rneese_> so no remaster specialist here
[13:27] <TheMuso> ogra_ac: hrm interesting indeed. I think I'd want to work out what causes most things for most people to work normally, i.e things go into /dev/snd, since there are no rules to do that on my system, so far as I can see, so I think it must be done at the kernel level.
[13:28] <ogra_ac> TheMuso, well, we used to have rules to create the devices in /dev/snd until lucid i think and gstreamers alsasink looks there for cards
[13:29] <ogra_ac> TheMuso, but i can well understand if there was an upstream decision to drop the old behavior
[13:30] <ogra_ac> the kernel by default creates them in /dev which is what we have today
[13:32] <TheMuso> ogra_ac: Hrm ok, I'll have to investigate that further, we may have missed something with packaging...
[13:32] <TheMuso> Anyway, afk.
[14:40] <rneese_> anyone here good with modifying the ubuntu-server iso to add a post install script
[14:41] <persia> rneese_, Generally post-install scripts are done on a per-package level, rather than per-image level (although the installer supports certain sorts of things if absolutely required).  I'd suggest describing the thing you wish to accomplish (not the technique by which you might do so) in #ubuntu-server.
[14:42] <rneese_> looking for a way to use the ubuntu-server iso to install a 1st boot script that will add pkgs and configure the system
[14:42] <rneese_> I wrote a script yesterday
[14:43] <rneese_> we are working to get a iso that builds our pbx system
[14:44] <rneese_> or make the iso install all the needed pkgs with out having to reboot to do it
[14:44] <persia> Oh.  You probably want to read the installation-guide for your architecture, and use some preseeding.
[14:44] <rneese_> looking at preceed.txt now
[14:44] <rneese_> thing is I have no understanding of how ubuntu does it compaired how we do it on bsd
[14:46] <rneese_> the preceed txt is just not easy to grep at first
[14:46] <cjwatson> simply installing extra packages can be done with pkgsel/include
[14:46] <cjwatson> general post-install commands can be run using preseed/late_command
[14:46] <cjwatson> you should be able to grep for those two keys
[14:47] <rneese_> well have to add the 3 repos
[14:47] <cjwatson> preseed.txt probably isn't particularly good - use https://help.ubuntu.com/10.04/installation-guide/i386/appendix-preseed.html
[14:47] <cjwatson> https://help.ubuntu.com/10.04/installation-guide/i386/preseed-contents.html#preseed-apt explains adding local repositories
[14:48] <rneese_> been reading but I guees its to diff from bsd my mind is not greping
[14:49] <rneese_> will read more
[14:50] <rneese_> I have to have a iso by end of the weekend
[14:51] <rneese_> thought maybe someone here was good enogh to look at the script and suggest/help with a cleaner faster way
[14:51] <rneese_> but dont want to overstep
[14:52] <cjwatson> I'm happy to look at an existing preseed file; I'm unlikely to be able to help with something done any other way
[14:56] <rneese_> I just found out about the preceed this am
[14:56] <rneese_> only have the script I wrote
[14:56] <rneese_> that might have to merge into the preceed
[14:58] <barry> ScottK: re: python2.7 on ppc.  yes, turn off the profiled build.  any chance you can also file a bug?
[14:58] <rneese_> http://pastebin.com/dWkf0E2F
[14:58] <rneese_> merging that into the preceed might be the answer
[15:01] <cjwatson> jcastro: is there anywhere to sign up for UDS lightning talks yet?
[15:01] <ScottK> barry: What would be bug be?  profiled build fails on powerpc?
[15:03] <barry> ScottK: if the non-profiled build succeeds, yep :).  attach or point to the buildlog.  i do have a powermac ppc dual g5 sitting around gathering dust.  would that make a decent machine to try this on?  i've dual booted my intel mbp, but haven't tried it on this ppc.  maybe i'll try that after uds
[15:04] <jcastro> cjwatson: no, we just line up on the friday
[15:04] <ScottK> barry: OK.  The bad news is I can't replicate it on the hardware I have access to.  Maybe you'll have more luck.
[15:04] <cjwatson> jcastro: ah, OK
[15:04] <jcastro> cjwatson: basically, sit in the front on Friday and we'll just line em up
[15:04] <rneese_> how ward would it be to make that script into a preceed file ?
[15:04] <cjwatson> righto, that allows for me to get cold feet with no shame attached. :-)
[15:04] <jcastro> cjwatson: an ARM guy sits up front with a tablet with a clock and that's basically it.
[15:05] <cjwatson> rneese_: probably not hugely, a lot of it seems to transfer over.  I can't do it all for you, but give me a minute and I'll sketch it
[15:05] <ScottK> barry: Uploaded.  We'll see.
[15:05] <barry> ScottK: +1.  also, i want to test it a little bit on a vm, but i think i'm ready to upload a new python-support to enable 2.7.  could you sponsor me on that in say an hour?
[15:05] <rneese_> ok it would help
[15:05] <jcastro> cjwatson: it's ok, james_w has the market cornered on botched demos, so you should be fine.
[15:05] <rneese_> I want to learn but
[15:05] <rneese_> its time consuming
[15:05] <ScottK> barry: Probably.  Any excuse to avoid working on a proposal that's due Monday.
[15:06] <rneese_> cjwatson: thnks ahead of time
[15:06] <rneese_> the file will be added to a iso
[15:07] <barry> ScottK: :)
[15:15] <cjwatson> rneese_: entirely untested, but I think something like http://pastebin.com/SQQV3q3v
[15:16] <rneese_> ok looking
[15:16] <cjwatson> rneese_: you should get static network configuration prompts during the installer itself with that
[15:16] <cjwatson> rneese_: please note that you can only assign one value to any given preseeding question, so I aggregated all your packages together into a single value for pkgsel/include
[15:16] <cjwatson> rneese_: also, of course, no point starting services given that preseed/late_command is run just before reboot
[15:17] <rneese_> ok I agree
[15:17] <rneese_> thansk
[15:17] <rneese_> reading it'
[15:17] <cjwatson> rneese_: see the installation guide for various ways to tell the installer to use the preseed file; I suggest also adding the DEBCONF_DEBUG=developer kernel parameter to the installer while you're working on this, which makes it easier to see what's going on
[15:18] <rneese_> ok
[15:18] <rneese_> reading and learning
[15:18] <rneese_> if your around is it ok to ask you questions if I dot grep ?
[15:19] <ogra_ac> does anyone know a way to find out if the currently running kernel matches the installed package version ?
[15:19] <ogra_ac> dpkg-query -W -f='${Version}\n' linux-image-$(uname -r)
[15:19] <ogra_ac> that gets me the packge version, but how would i know this verysion is what is being executed ?
[15:19] <cjwatson> rneese_: oh, blast, bit of a mistake in preseed/late_command since everything needs to be done inside the chroot, will edit
[15:20] <cjwatson> rneese_: yes, but #ubuntu-installer might be better than here
[15:20] <ogra_ac> (if the ABI is the same indeed)
[15:20] <ION> ogra: /var/log/dmesg’s third line perhaps.
[15:20] <ogra_ac> ION, nope, also only up to the ABI
[15:20] <rneese_> ok I joined installer
[15:21] <ogra_ac> ah, no, there is a version at the end of the line too
[15:21] <ogra_ac> ugh, that will be ugly hackery to extract
[15:22] <ION> /proc/version_signature
[15:22] <ogra_ac> ION, perfect ! thanks
[15:24] <ScottK> siretart: xine-lib has my name on it on m.u.c since I rebuilt it for a transition, but I'd be ever so grateful if you'd merge it.
[15:34] <ScottK> cjwatson: Would you please rescore python2.7 (powerpc).  I'd really like to see if we can get 2.7 built there.
[15:37] <cjwatson> ScottK: done
[15:41] <ScottK> cjwatson: Thanks.
[15:42] <seb128> cjwatson, I think one of the issues with bug triaging is that different maintainers have different workflows
[15:44] <seb128> (cjwatson, just commenting after reading your reply on the list)
[15:45] <seb128> some people like to keep the noise out of the buglist so they can handle it, some other just want things to stay on state until they have time to investigate issues
[15:46] <seb128> cjwatson, not sure that lettings bugs without any reply for years reflects better on Ubuntu though...
[15:46] <seb128> no easy solution either way though
[15:49] <ScottK> seb128: I'd say that people feeling the need to mark bugs closed in order to declutter lists suggests we need better bug searching/list making.
[15:51] <cjwatson> seb128: do you disagree with me that bug triage is a skilled task, though?
[15:51] <cjwatson> I thought that we could find common ground at least on that
[15:52] <cjwatson> it may be that bug triagers manage to do better on desktop packages, for instance, since it's often easier for them to fire up the application and have a look
[15:52] <cjwatson> I mean it may be that relatively unskilled bug triagers manage to do better ...
[15:56] <ScottK> cjwatson: Most of the "Is this still a problem -> Incomplete" responses I see there's no evidence that anyone even tried to reproduce the problem themselves.
[15:57] <cjwatson> I wonder if there's some mileage in adding some exhortations to whatever wiki page those responses come from
[15:58] <ScottK> I was thinking more like threaten to smack people who don't at least try to replicate it themselves first, but yeah.
[15:58] <cjwatson> or edit the response on the wiki page to have something like "[Edit this to say what you tried to do to reproduce the problem.  Dear reporter: if this sentence is in the message you retrieve, then feel free to ignore this message as the bug triager wasn't paying attention.]"
[15:58] <ScottK> heh.
[15:58] <ScottK> bdmurray: ^^^ What do you think?
[15:58] <ScottK> Sounds good to me.
[15:59] <cjwatson> seb128: I agree it isn't good to have bugs not getting replies - I just don't really think form letters count :-)
[15:59] <persia> I've gotten that class of response to some of my more obvious bugs (e.g. apt-get source linux doesn't), but I'm not sure we can usefully change behaviour simply by adding more to the wiki page.
[16:00] <persia> Lots of the newest folks seem to want to focus on volume of bugs touched, rather than usefulness of work done, which probably indicates some lower-level issue.
[16:00] <chrisccoulson> i've seen people ask the reporter if their bug still occurs in the latest release, despite the particular application being removed from the archive several releases ago.....
[16:00] <chrisccoulson> ....which obviously means people aren't trying to reproduce problems for themselves
[16:00] <ScottK> Nice.
[16:00] <seb128> cjwatson, sorry got sidetracked, yes we agree that triaging is a skilled tasks
[16:01] <seb128> ScottK, well closing bugs is a way to tag them to be out of the default list
[16:01] <ScottK> chrisccoulson: I think it's one of the inherent side effects of keeping bug metrics.  People see a number and want to make it go in the right direction.
[16:01] <seb128> they are not deleted from launchpad
[16:01] <persia> Note that in the special cases of X and the kernel, there are *heaps* of absolutely useless bugs that nobody but the submitter can reliably reproduce because they are related to some specific piece of flaky hardware.
[16:01] <seb128> the issue is not metric
[16:02] <seb128> the issue is to be able to open a bug list and to have something you can work on
[16:02] <persia> ScottK, You suggest we should drop the metrics?
[16:02] <ScottK> seb128: I think for triagers it can be.
[16:02] <persia> seb128, I don't believe I can usefully do that based on current triage policies.
[16:03] <ScottK> persia: I think if we keep them, we have to engage in work to discourage unhelpful practices they encourage.
[16:03] <persia> ScottK, I'd rather do that, as I have found them motivating in some ways (although maybe for the wrong reasons).
[16:04] <ScottK> persia: It's a matter of recognizing the unhelpful consequences of them and dealing with them.
[16:04] <cjwatson> seb128: my problem is that I want to decide what I want to work on myself, and I find that I spend too much time overruling triagers' incorrect decisions on what they think I should work on ...
[16:04] <cjwatson> so maybe we have similar goals but different problems leading up to them
[16:05] <cjwatson> merge@casey:/srv/patches.ubuntu.com/code$ time ./syndicate.py -q
[16:05] <cjwatson> real    3m50.843s
[16:05] <cjwatson> that's more like it.  it was well over half an hour before
[16:05] <siretart> ScottK: new xine requires graphicsmagick-libmagick-dev-compat, which is in universe. do you know if there are plans to promote it to main?
[16:05] <cjwatson> (that's not all of MoM, just a particularly slow bit I noticed)
[16:05] <ScottK> siretart: Not until you write the MIR I would guess.
[16:05] <ScottK> (no idea really)
[16:06] <seb128> cjwatson, well ideally yes, but really is that the number of bugs we get just means in the end we don't have time to read half of the incoming ones
[16:06] <siretart> hm, I don't really fancy that idea...
[16:06] <seb128> really -> reality
[16:06] <seb128> cjwatson, just letting things stacking doesn't make any better and realistically we will just never come back to most of those waiting for a year
[16:06] <persia> seb128, I think it's highly package-dependent.  I've often found time to read 6-12 months of old untouched bugs for some arbitrary package (which clearly didn't get much triage), if it mostly works.
[16:07] <cjwatson> seb128: what happens to me is that I get people coming in and asking for more information when the bug doesn't need it and when I've already commented on it with details
[16:07] <seb128> persia, well you probably don't pick things like ubiquity
[16:07] <cjwatson> seb128: that sort of thing just wastes my time for absolutely no benefit to anyway
[16:07] <cjwatson> *anyone
[16:07] <cjwatson> I don't see how the issues of bugs stacking up over time really relates to that
[16:08] <seb128> cjwatson, right, the issue is not bugs being set to incomplete and expiring then
[16:08] <cjwatson> um, but that's exactly what's going to happen to me
[16:08] <seb128> it's people doing bug triaging who don't know what they are doing
[16:08] <cjwatson> sure, but we're implementing this expiry policy based on the assumption that triagers know what they're doing
[16:09] <cjwatson> or perhaps based on the assumption that somebody with clue is going to have time to clean up in cases where that wasn't the case
[16:09] <seb128> well I find the expiry feature useful
[16:09] <seb128> it means I don't need to care about cleaning bugs I set to incomplete
[16:09] <cjwatson> it would be useful if the statuses weren't such a mess as it stands
[16:09] <cjwatson> maybe there should be some detection of who set the bug to incomplete
[16:09] <seb128> right
[16:10] <seb128> I think we agree that the issue is not bugs set to expire
[16:10] <seb128> is that triaging is done wrongly
[16:10] <cjwatson> anyone at all can mark a bug Incomplete
[16:10] <cjwatson> there is absolutely no access control on that
[16:10] <seb128> we should perhaps restrict the set of people who can do that
[16:11] <cjwatson> well, aside from "must have an account"
[16:11] <seb128> to the same people who can set priority etc
[16:11] <cjwatson> I think that might help
[16:11] <persia> Can we do that *before* we auto-expire more bugs?
[16:12] <seb128> ideally we would have a way to say whether as the maintainer you care about this bug or not
[16:13] <seb128> like "keep it on the list of things I want to know about" or "just get it out of my way"
[16:13] <seb128> the first category should be things that random people are not able to modify
[16:13] <persia> Some sort of integrated project/task management in Launchpad?  mpt had some interesting ideas about that.
[16:13] <seb128> the second ones is things you know as a maintainer that are nothing useful to you and can go to triagers or answer tracker or whatever
[16:14] <cjwatson> like "all crash reports"? :-)
[16:14] <seb128> the "doesn't work, please help" descriptions
[16:14] <cjwatson> it would really help for crash reports to be a separate database, but we knew this ...
[16:14] <seb128> well stacktrace are often useful
[16:14] <cjwatson> the workflow I'd like is for a developer to be able to promote a crash to a bug once it's been analysed
[16:14] <seb128> but there is lot of user questions or requests for help coming as bugs
[16:14] <cjwatson> same way you can promote a question to a bug
[16:15] <seb128> right...
[16:15] <cjwatson> but I don't hold out a lot of hope of this happening
[16:15] <persia> seb128, But we should be using convert-to-question for that, not incomplete.
[16:15] <seb128> well people argue that "doesn't work" is still a bug
[16:15] <seb128> it just that it doesn't have enough information about the issue to be useful
[16:15] <seb128> those are different from real question, like "how do I do that"
[16:15] <cjwatson> I think I would say that it isn't a bug yet
[16:16] <seb128> well that's what we use incomplete for atm
[16:16] <cjwatson> but it might be if it were made more precise
[16:17] <seb128> right
[16:18] <seb128> the thing is that the way you get things out of the list is to set those incomplete
[16:18] <robbiew> cr3: I'm assuming you want a UDS session for https://blueprints.edge.launchpad.net/certify-planning/+spec/other-ps-n-manual-testing-patterns, right?
[16:18] <seb128> but ideally you should tell the submitter what is missing when you set to incomplete
[16:19] <seb128> there is no way right now to say "that's not useful to me but I've no time to be the one helping to get the required informations"
[16:19] <cr3> robbiew: if there's an available slot, it would be nice
[16:19] <mpt> Like ScottK, I have sometimes felt the urge to smack people who didn't even try my steps to reproduce before marking a bug as Incomplete
[16:19] <persia> seb128, So we maybe need to change the training for bugsquad?  I'm not sure that most triagers currently know what is missing.
[16:19] <seb128> or to put on a list "needs to be triaged by somebody"
[16:19] <ScottK> I'd really like to get away from the "we haven't heard from you in a while, please prove it's still a problem".
[16:20] <robbiew> cr3: done ;)
[16:20] <persia> ScottK, In practice, bugsquad typically doesn't do that anymore (although our information dissemination procedures are fairly slow in bugsquad).
[16:20] <seb128> we do
[16:20] <mpt> but the purpose of a bug tracker is not to record every bug that exists or might exist in software
[16:20] <ScottK> robbiew: Are you accepting other-* specs?
[16:20] <persia> seb128, Only the Desktop team, and only for Desktop bugs, because you insist.
[16:21] <persia> mpt, Why not?  How else do we know what we can fix?
[16:21] <cr3> robbiew: that was easy, I should propose a bunch of other sessions if it's that easy! :)
[16:21] <seb128> that's the only way to clean the list of weird issues who happened one time to one user in an old version
[16:21] <seb128> things we have no clue about and just let there because we didn't know what to do with them
[16:21] <robbiew> ScottK: I'm accepting whatever's needed ;)
[16:21] <robbiew> cr3: heh...well, it's not THAT easy
[16:22] <ScottK> OK.  Let me find it.
[16:22] <mpt> persia, because the purpose of a bug tracker is to help engineers make best use of their time. And usually, spending an hour fixing a bug will improve the software more than spending that hour trying to clarify an incomplete bug report.
[16:22] <seb128> but realistically those are often not useful especially if it happened once to one user and not for years
[16:22] <persia> seb128, So, most of those would be better to try to reproduce, etc., no?
[16:22] <persia> seb128, In my experience, it's not that hard to reproduce something in e.g. feisty (from oldreleases), and then show it fixed in e.g. maverick, and so mark a bug closed.
[16:22] <seb128> lot of those are not reproducable
[16:23] <seb128> it's a thing one user got one time without knowing how
[16:23] <persia> Even in the original environment?
[16:23] <seb128> and nobody has got since
[16:23] <seb128> yes
[16:24] <persia> mpt, I think it very much depends on the nature of the issue.  As an example, how about "Ubuntu hardy boots really slow".  That was a worthwhile bug to fix, although it took *months* of developer effort to get it even close to being a useful bug report.
[16:25] <mpt> persia, sure, I'm not saying there are no exceptions
[16:25] <ScottK> robbiew: Nevermind.  It got accepted while I wasn't looking.
[16:25] <persia> mpt, I guess I'm saying I think every real bug is worth tracking (even when it can only be reproduced in hungarian on a full moon (real example))
[16:26] <ScottK> The existence of an incomplete bug may be a key for someone else who has the problem to come along later and add needed information.
[16:26] <robbiew> ScottK: ;)
[16:26] <ScottK> I've, more than once, seen people not report bugs because they thought it was "just them".
[16:27] <maco> persia: or on tuesdays?
[16:28] <persia> Although some secondary reporters damage the utility of a bug, sadly, just because of apparently similar symptoms.
[16:28] <persia> maco, I've yet to see a bug that only happens on Tuesdays (there was one about Thursdays, but that was in a closed-source project)
[16:29] <maco> persia: hmm i thought the printer bug was on tuesdays
[16:29] <persia> Might be: I didn't see that one.
[16:30] <maco> yeah... OOo couldnt print to Brother printers on Tuesdays
[16:30] <cjwatson> mpt: my experience is that this argument is extended to ridiculous extremes, including removing things from my to-do list that I've already acknowledged as bugs and just haven't got round to yet.
[16:30] <maco> https://lists.ubuntu.com/archives/ubuntu-users/2009-April/182642.html
[16:30] <cjwatson> mpt: I certainly agree that endless back-and-forth to try to clarify "my computer doesn't seem to be working quite right" is not a good use of engineering time
[16:31] <maco> cjwatson: isnt that why there are triagers-who-arent-devs?
[16:31] <mpt> cjwatson, I don't think the human Incomplete-bots are working on the basis of any particular argument. :-)
[16:31] <cjwatson> maco: yes; but there is a limit to how far from a developer skill level I think they ought to be
[16:32] <cjwatson> mpt: when challenged, they generally say that they didn't think the bug report could have been valuable if it had stayed around for so long (where "so long" can be anything from a week up)
[16:32] <maco> cjwatson: fair enough. i quickly run out of steam on bugs in non-gui programs
[16:32] <maco> (  *frown*  )
[16:39] <siretart> ScottK: seems that build dependency isn't strictly necessary; package builds and seems to work without for me
[16:39] <siretart> ScottK: uploaded
[16:39] <ScottK> siretart: Cool.  Thanks.
[16:48] <ScottK> Related to the whole bug expiration question: http://lwn.net/Articles/410846/
[17:59] <rneese_> when remastering a iso where do you place a custom preceed.cfg file ?
[18:06] <lool> cjwatson: FYI latest tasksel fails to upgrade for me: Erreur d'analyse de message vers « Description-sr@latin.UTF-8: Izaberite softver za instaliranje: », dans la partie #1 de /var/lib/dpkg/info/tasksel.templates
[18:07] <lool> https://bugs.launchpad.net/ubuntu/+source/tasksel/+bug/665178
[19:13] <smoser> barry, are you able to fix https://bugs.launchpad.net/ubuntu/+source/python-crypto/+bug/662883
[19:14] <smoser> (mainly asking if you have commit privs to python-crypto, or if we need someone to sponsor it)
[19:18] <smoser> ScottK, would you feel comfortable sponsoring that now ? we have a placeholder "fix it right" bug around.
[19:18] <smoser> i'd really like to move on to the next hurdle for natty uec images
[19:19] <shadeslayer> rickspencer3: around?
[19:19] <rickspencer3> hi shadeslayer how can I help?
[19:20] <shadeslayer> rickspencer3: whats the Gifting plenary about?
[19:20] <rickspencer3> shadeslayer, about how Ubuntu is a gifting culture
[19:20] <rickspencer3> it's totally mushy
[19:20] <rickspencer3> not at all technical
[19:20] <shadeslayer> ah ohk ...
[19:20] <rickspencer3> 4 freedoms -> Ubuntu Manifesto -> CoC -> how we behave
[19:22] <smoser> totally mushy
[19:22] <rickspencer3> shadeslayer, were you worried I was going to pass around a collection plate?
[19:22] <rickspencer3> ;)'
[19:22] <statik> kirkland: all these blog posts about bikeshed have me wanting to install it, but the package is stuck in new. cmon dude, stop teasing ;)
[19:22] <persia> Note that there are other equally valid ways to interpret such things.  The "You are all my slaves, making everything work because you are hopelessly addicted to my code" works well for some folks.
[19:23] <shadeslayer> rickspencer3: hahaha .. no, was just wondering if we had to bring gifts for other people attending the plenary :P
[19:23] <kirkland> statik: fixed
[19:24] <statik> awesome
[19:26]  * smoser now has 'signs' stuck in his head due to the 'pass the plate' reference above.
[19:31] <barry> hi folks.  can i get a sponsor to upload new python-support and python-central packages to enable py2.7 in natty?  tested locally, it seems to be working as expected
[19:32] <persia> barry, If you don't get a response soon, either use UDD and file some merge requests (which automatically end up in the sponsors queue), or file a bug and attach relevant information so folks can get your packages.
[19:34] <corecode> hi
[19:34] <barry> persia: i have merge requests open already
[19:34] <corecode> anybody know where eglibc people hang out?
[19:35] <persia> barry, Excellent.  I just try to guard against lots of sponsorship requests in other channels: my experience is that when there's lots of requests in other places, the sponsors queue gets ignored.  When more folk are using the sponsors queue, latency goes down.
[19:36] <barry> persia: nod, thanks.  what is average turn around time for merge proposals?  or iow, how patient should i be? :)
[19:42] <geser> barry: if it didn't change much recently, you probably need to go hunting for a sponsor if you want get it sponsored fast
[19:42] <barry> geser: is this the right forum for that?  i really do want to get these uploaded before weekend/uds
[19:44] <geser> barry: yes, but you might have trouble find a core-dev now as it's a) weekend and b) many are travelling to UDS
[19:44] <geser> you might have better chance to bribe a core-dev at UDS :)
[19:44] <persia> barry, The nice target is 3-4 days, but, especially for stuff in "main", sometimes it takes weeks, sadly.  If you need it pre-UDS, you will need to find someone (and this is a forum that has folks that can do it, although see above for why I don't think asking for quick sponsoring is good for the overall health of contributions by folk without direct upload rights)
[19:45] <barry> geser, persia gotcha, thanks.  see you at uds
[20:58] <rneese_> anyone here good at remastering the server iso
[20:58] <rneese_> it seems like a pain to remaster
[22:06] <ScottK> smoser: Maybe in a few hours.  Still tied up with other stuff.
[22:52] <avo> Hey guys.. so I'm writing a SUPER small app that is literally only useful to one or two other people (my friends.. it's about our school). However, I'd like them to be able to code the little project as well, and use a system to keep all this straight. There's no reason, and frankly I wouldn't want to make this visible to the public. How/can I do this? Thanks!
[22:54] <persia> avo, If you just want have a shared source repository to collaborate with a couple friends, you might want to store your code in bzr on launchpad.  The folk in #launchpad would be happy to help you get started.
[22:55] <avo> That sounds great.. I'll head on over there. Thanks!
[23:00] <corecode> i can't wrap my head around bzr... too much git
[23:01] <corecode> i updated roundcube, anybody interested in getting this in?
[23:28] <bjf> jdstrand, Could I trouble you to "New" some kernel uploads for me?  karmic, lucid and maverick
[23:28] <jdstrand> bjf: that is a lot of uploads for eod on friday...
[23:29] <jdstrand> bjf: I'll take a look
[23:29] <bjf> jdstrand, thanks
[23:30] <bjf> jdstrand, we're still recovering from the security release
[23:30] <jdstrand> that's cool
[23:30] <jdstrand> bjf: my day just ended up being not at all what I expected. no worries
[23:31] <jdstrand> bjf: (nothing to do with your request)
[23:31] <bjf> jdstrand, glad to hear it's not me
[23:49] <YokoZar> Any known issues with libc6 on 10.10?  My friend reported a clean install causing a broken package on first update manager run...
[23:53] <TheMuso> YokoZar: He's not using -proposed I hope.
[23:53] <YokoZar> TheMuso: nope
[23:54] <wgrant> There was a security update a few hours ago...
[23:54] <wgrant> But "broken package" isn't terribly descriptive.
[23:55] <YokoZar> wgrant: by broken I mean doesn't install
[23:55] <YokoZar> getting more info now ;)