[00:45] <what_if> Need a bit of help getting started... want to work on the "system restore/rollback functionality" requests in ubuntu brainstorm. Where do I start? Where is code hosted, etc.
[00:46] <kklimonda> well, all code is store on launchpad
[00:48] <kees> ScottK: heh, thanks.
[00:50] <crimsun> some people just don't get it, eh?
[02:30] <psusi> anyone around know initramfs-tools well?  I'd like to interface with it to create an alternate initramfs that has defrag built into it to perform boot time defrag of the root fs
[03:07] <nxvl> does anyknow knows how to create a patch with dpkgsrc 3.0?
[03:10] <RAOF> nxvl: You mean 3.0 (quilt)?
[03:10] <psusi> doesn't that just mean it uses quilt?
[03:10] <nxvl> yup
[03:10] <nxvl> psusi: oh no, it does a lot of fancy stuff
[03:11] <psusi> export QUILT_PATCHES=debian/patches ; quilt new my-patch ; quilt add somefile ; edit somefile ; quilt refresh
[03:11] <RAOF> Yeah.  It's actually just quilt.
[03:11] <psusi> and you might want to quilt push -a before the new if you want your patch to be applied after all the existing ones
[03:14] <arand> If I want to debug fsck failing with an error when user cancels the check, what would I do? Is this backtrace useless?: http://pastebin.com/MZkMc1UN (I lack all kinds of gdb-foo).
[03:14] <psusi> what's to debug?  if they canceled the check, that is an error
[03:15] <nxvl> oh, ok thanks!
[03:16] <arand> psusi: So "fsck.ext4: Inode bitmap not loaded while setting block group checksum info" exit code 8. Is correct behaviour for fsck on user cancelling the check?
[03:16] <psusi> arand, no, that's fsck finding an error with the fs, not being canceled
[03:17] <psusi> wait, no...
[03:17] <arand> psusi: But there are no errors in the filesystem, if fsck runs through okay.
[03:17] <arand> Error is _only_ seen when it is cancelled.
[03:17] <psusi> sounds like an assertion failure triggered by the sigint... search the code for that string
[03:18] <psusi> sounds like the canceling tries to do some cleanup in the SIGINT handler, and part of that cleanup is trying to write out the inode allocation bitmap, which an assertion check makes sure is actually loaded first and it isn't
[03:19] <psusi> it may not be loaded either because it has not been loaded yet at the time of the SIGINT, or because that block group's inode allocation bitmap is uninitialized
[03:19] <shtylman> ccheney: there is no UbuntuLucid config in go-oo trunk... is that normal? what do you use to build?
[03:22] <arand> psusi: https://bugs.edge.launchpad.net/bugs/582035 is the bug, I think at least 80% of what you're saying is over my head :/ So please put a comment if you've got some good theories :)
[03:23] <psusi> arand, first thing I'd do is search the source code for the string "Inode bitmap not loaded while"
[03:24] <arand> psusi: I'm on it.
[03:24] <psusi> arand, my guess is you will find an assert() with that string in it and that assertion is failing because of a race condition in which the inode allocation bitmap is not loaded yet, but should be eventually... and that could be a little tricky to fix
[03:25] <psusi> but I have a feeling that probably it is not loaded because that block group's inode table is uninitialized in the first place.. meaning there are no inodes used in that block group so the allocation table is not actually valid and a flag says it is unused, assume it's all empty
[03:26] <psusi> fixing that should be as simple as putting in a check for the uninitialized flag in the code trying to flush the allocation bitmap and bail out of it is set
[03:39] <arand> psusi: I feel like I should probably take the backlog here and paste it to the bug or something, because I have absolutely zero knowledge when it comes to FSs... Here's what I dug up in the source (again, I have no idea what is relevant...): http://pastebin.ubuntu.com/435281/
[03:40] <ccheney> shtylman: ah i hadn't synced up trunk yet from 3-2 branch
[03:41] <psusi> arand, good time to learn ;)
[03:47] <arand> Hmm, if only things were that simple... :)
[04:06] <arand> psusi: Hmm, well staring at this code gives me nothing.. :(   Would you mind (and do you think it would be useful?), if I pasted the backlog of our talk here to the bug?
[04:07] <psusi> I don't mind, no... and sure it could be useful
[04:08] <arand> Ok, will do then.
[04:34] <TheMuso> crimsun: Do you know why we have ac97 related patches in alsa-driver even though they don't get applied?
[05:06] <Chipzz>  ~.
[06:09] <crimsun> TheMuso: which, the via ones?
[06:16] <crimsun> TheMuso: add_onda_a69g_ac97_support.patch was backported from upstream, so it isn't applied in lucid's. add_suspend_quirk_hp_nc6220_nw8240.patch and refix_lp_68659_by_disabling_dxs_for_0x1458a002.patch are both mine and need to be pushed.
[06:17] <TheMuso> crimsun: Right, I worked it out.
[06:17] <TheMuso> crimsun: thanks
[06:34] <loneowais> hey everyone... does anyone know how to get my appindicator into the messaging menu?... Python-Api ?
[07:13] <dholbach> good morning
[07:15] <pitti> Good morning
[07:32] <loneowais> Is storing passwords in dekstopcouch ok?... can i encrypt them? how?
[07:36] <RAOF> loneowais: You probably want gnome-keyring, which does a bunch of heavy lifting to make password storing work well.
[07:37] <loneowais> RAOF: that's what i thought.. but couch syncs with ubutnu-one
[07:38] <RAOF> loneowais: So a solution would be to make gnome-keyring store the keyring in desktopcouch :)
[07:39] <loneowais> RAOF: that would be nice...for all the ubuntu apps
[07:39] <loneowais> :-)
[07:39] <RAOF> loneowais: It *would* be nice to have all my passwords sync'd across to all my computers, but not in a way that stores them in plaintext on a internet server!
[07:40] <loneowais> RAOF: right.
[08:05] <tjaalton> tkamppeter_: hi, I've got the symptoms of bug 420490 but due to just restarting the cups server
[08:05] <tjaalton> so no upgrades in between
[08:05] <tjaalton> need to remove /var/cache/cups/*.ipp and restart it to make printing work again
[08:06] <tjaalton> and this is only on lucid, the same ppd/queues work fine on hardy/jaunty
[08:39] <mdke> cjohnston: sure
[08:39] <mdke> cjohnston: sorry, wrong nick
[08:39] <mdke> cjwatson: sure
[08:43] <jussi> poor cjohnston...
[09:25] <[Crono]> hi all
[09:25] <[Crono]> good morning
[10:13] <coz_> hey guys... for several years now ubuntu has this bug that when booting  it drops to busybox  because of my scsi drives.. and many of the bug reports I have seen  give a  solution  of add a rediculous rootdelay-40 to grub... << on lucid I can drop that to rootdelay=35...is there possibly any other solution?  this does not happen with any other distribution
[10:26] <pitti> cody-somerville, mr_pouit, cjwatson: how does xubuntu manage to install the non-preferred gdm dependencies (xfce4-session and xfwm4) first, before gdm pulls it in? the seed order doesn't seem to make any difference?
[10:27] <pitti> "pulls it in" -> "pulls in half of GNOME
[10:27] <hyperair> persia: could you add me to ubutnu-sponsors please?
[10:27] <hyperair> ubuntu*
[10:28] <persia> hyperair: Sure.
[10:28] <hyperair> persia: thanks.
[10:55] <pecisk> hi people, does i386 version of netbook edition has same fallback mechanism when dealing with non-accelerated graphics using Enlightment libs?
[10:56] <RAOF> pecisk: Yes
[10:57] <pecisk> RAOF, great, thanks for answer :)
[11:09] <dholbach> persia: should https://wiki.ubuntu.com/UbuntuDevelopers and https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess list package sets?
[11:09] <dholbach> I think they should to avoid confusion
[11:12] <persia> dholbach: Probably.  More generally, they likely need a revamp to reflect the practices developed over the past few months, rather than the initial ideas.
[11:12] <dholbach> good
[11:12] <persia> dholbach: Where it gets tricky is that some packagesets aren't defined in very clear terms.
[11:13] <dholbach> still should the use-case for developers be pretty simple: take a look at the list, decide which upload rights you need, apply for them :)
[11:13] <persia> Or rather, not defined in easily-discoverable terms.
[11:13] <dholbach> right
[11:13] <persia> I think that's entirely the wrong use-case.
[11:13] <jml> james_w, were notes taken for "Review and Planning for Distributed Development"? I can't find the gobby doc.
[11:14] <persia> I think that someone ought work with some team(s), and have the team suggest that the person join that development team.
[11:14] <persia> anyone just randomly looking at the list is very likely to be disappointed with the decision of the board.
[11:14] <dholbach> persia: that somebody needs upload rights for a certain set of packages does not mean that they didn't work with that team
[11:15] <dholbach> but anyway, we're splitting hairs
[11:15] <dholbach> I just wanted to write a blog post about which permissions reorg changes have been implemented and noticed it wasn't mentioned as clearly as I thought
[11:16] <persia> It's all implemented, but the documentation is a bit spotty, in part because the various social definitions haven't been finalised.
[11:17] <dholbach> ok
[11:19] <cjwatson> pitti: we normally install by task
[11:20] <persia> For the short-term, it's probably best to indicate that folks ought know what sort of upload rights they want: if it's in a (short) list, they ought talk with the developers concerned.  if not, they ought talk to the DMB, who may be able to arrange that they can do what they need.
[11:20] <pitti> cjwatson: ah, and there the seed order matters?
[11:22] <cjwatson> pitti: seed order itself should not matter, but germinate "plants" anything that is explicitly seeded before trying to resolve broken dependencies
[11:22] <pitti> cjwatson: ah, thanks
[11:23] <cjwatson> once you get down into resolving dependencies, it's (IIRC) depth-first, but the very top level is more like breadth-first
[11:39] <james_w> jml: there were notes
[11:40] <jml> james_w: where can I find them?
[11:40] <james_w> weren't some gobby documents lost though?
[11:41] <jml> james_w: that's what I heard. all of the other gobby docs that I care about managed to survive though.
[11:45] <james_w> jml: I can't see it either
[11:47]  * jml checks IRC logs...
[11:49] <jml> frustratingly, the gobby doc name isn't mentioned.
[11:50] <dholbach> mako, mdke: are you guys going to be in the CC meeting in 10m?
[11:52] <jml> james_w: I've just put a note on the whiteboard for the spec calling for notes. Anything else I should do?
[11:52] <cjwatson> gobby is supposed to be backed by bzr on the server side; ask IS if they can hunt around
[11:52] <jml> cjwatson: wil do. thanks.
[12:08] <pitti> does anyone know what actually uses /usr/share/i18n/charmaps/* ?
[12:14] <cjwatson> pitti: localedef
[12:14] <pitti> cjwatson: ah, thanks
[12:17] <soren> Do we really use anything other than UTF-8 in there by default?
[12:17] <pitti> soren: not by default
[12:17] <pitti> soren: but the charmaps compress nicely into 3.1 MB, so I'd like to teach localedef to get along with gzipped ones
[12:17] <soren> That's an easy 14 MB save on a minimal install.
[12:17] <soren> pitti: Ah, yeah, that's good too.
[13:04] <Riddell> lamont: how come you didn't use a -0ubuntu1 version number for gcc-opt?
[13:13] <lamont> Riddell: prolly because I didn't upload it to debian
[13:13] <lamont> then again, it was more of a dump-n-run than anything I care to ever support again
[13:14] <lamont> dead upstream, there are parts of ubuntu that may choose to use that as a start of an idea for something, but otherwise, I expect that to be the last upload of gcc-opt ever
[13:15] <Riddell> you're not selling it to me :)
[13:16] <lamont> cjwatson asked me to put it somewhere.  universe was the decided target....
[13:16] <Riddell> accepted
[13:16] <lamont> ta
[13:40] <cjwatson> cking,NCommander,superm1: I don't suppose any of you have notes from foundations-m-btrfs-support?
[13:40] <cjwatson> (or anyone else)
[13:42] <cjwatson> oubiwann_: ^-
[13:55] <NCommander> cjwatson: don't think so :-/
[14:02] <jml> oubiwann_, hello. I just discovered the gobby doc for https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-m-cycle-review
[14:03] <jml> oubiwann_, in the "Lessons learned" section, there's "launchpad bugs situation really needs to be addressed for Foundations"
[14:03] <jml> but no more information.
[14:04] <cjwatson> jml: I think where that's coming from is that some of our team are drowning in bugmail to the extent that they find it difficult to get actual work done
[14:04] <cjwatson> I don't think it's specifically Foundations though
[14:05] <jml> cjwatson, tbh, I didn't get many other people complaining about too much email.
[14:05] <jml> cjwatson, but there are many other possible reasons for that
[14:05] <cjwatson> Keybuk in particular had this problem towards the end of the cycle
[14:05] <cody-somerville> cjwatson, do you have any plans to merge base-installer any time soon?
[14:06] <cjwatson> cody-somerville: at some point in the merge window, sure
[14:06] <jml> cjwatson, thanks.
[14:06] <jml> cjwatson, the bugs team is working on improving the too much email situation -- I'll make sure that we talk to Keybuk as a part of that.
[14:06] <cjwatson> thanks
[14:07] <jml> cjwatson, was there anything else LP-related in the 10.04 review session?
[14:08] <cking> cjwatson, no notes from foundations-m-btrfs-support :-(
[14:08] <cody-somerville> cjwatson, live-installer in debian has made a change thats dependent on a newer version of base-installer (ie. adding a new waypoint for a script in newer base-installer). I was thinking of removing the waypoint and modifying the dependency to require a version less then the version of base-installer the change occurred in so that re-adding the waypoint won't be forgotten about. Does this sound sane to you?
[14:09] <cjwatson> jml: I don't have it paged in at the moment, but if I think of anything I'll let you know ... most of the discussion wasn't about LP though
[14:09] <cjwatson> cking: thanks anyway
[14:09] <jml> cjwatson, thanks.
[14:09] <cjwatson> cody-somerville: not really, why not just be a little bit patient?  I'll be merging base-installer in the not too distant future
[14:11] <cody-somerville> cjwatson, because I already merged live-installer and so it currently does not work. Frans Pop didn't modify the deps to indicate the newer version of base-installer was needed.
[14:14] <cjwatson> cody-somerville: *shrug* the merge cycle is always like this.  please don't create more work by working around it
[14:15] <cjwatson> better to simply wait; it won't be that long
[14:19] <cody-somerville> cjwatson, patching live-installer's deps to say it requires the newer base-installer would be correct though, eh?
[14:21] <cjwatson> cody-somerville: we don't usually bother that much with versioned dependencies in d-i, since nothing processes them at run-time
[14:21] <cjwatson> their only practical use is to control transitions to Debian testing
[14:21] <cjwatson> so they'll often get removed after a period of time to reduce size
[14:21] <cjwatson> honestly, I wouldn't bother if I were you
[14:23] <cody-somerville> alright. thanks for the advice. I appreciate it. :)
[15:01] <mathiaz> seb128: hi!
[15:01] <mathiaz> seb128: what is ~/.gconfd/saved_state used for?
[15:05] <chrisccoulson> mathiaz, that file logs listeners, so that they can be restored if gconfd restarts
[15:05] <mathiaz> chrisccoulson: ok - so there is no point in putting this file under version control
[15:06] <chrisccoulson> mathiaz, no, i wouldn't bother doing that
[15:06] <mathiaz> chrisccoulson: great - thanks!
[15:09] <jcastro> whom do I talk to about making sure a package is blacklisted from being merged from debian?
[15:12] <james_w> jcastro: you can file a bug and subscribe ubuntu-archive
[15:12] <jcastro> ok
[15:12] <james_w> it won't prevent it, but stop it being listed by merges.ubuntu.com and the like
[15:12] <jcastro> james_w: on the specific package?
[15:12] <james_w> yeah
[15:32] <bladernr_> Hey, I have a question... how difficult would it be to get a couple more sample files included in /usr/share/example-content?
[15:33] <bladernr_> I see most standard doctypes included as samples, but no pdfs
[15:41] <kklimonda> bladernr_: we are limited by the amount of the free space on live cd
[15:41] <cjwatson> including extra small files wouldn't be much of an issue
[15:44] <bladernr_> cjwatson:  I was just thinking about including a .pdf, seems that directory has pretty much all common doc types, except for pdf
[15:46] <xnox> If my merge proposal is marked "Needs Fixing" should I just push new revision & comment that I've fixed the issues. Or shall I click "resubmit" merge proposal?
[15:46] <bladernr_> right now, we're discussing (in QA) just including sample files inside the checkbox package instead, I was just interested in using example-content since it's already there, so no need to duplicate data
[15:47] <cjwatson> file a bug report, and discuss with whoever uploaded it last :)
[15:49] <james_w> xnox: if it's a small change then just comment and change it to "Needs Review". If you took a completely different approach then you can "Resubmit".
[15:50] <xnox> ok thanks james_w
[15:53] <pitti> Riddell: ah, you're doing syncs ATM?
[15:53] <Riddell> pitti: I am yes
[16:09] <pitti> kees, jdstrand: I prepared new psql packages for all stables and set up bug 582299 to track the progress; should I do anything further now?
[16:11] <kees> pitti: if it's related to security, we'd need the debdiffs for us to upload.
[16:12] <pitti> kees: oh, not just the source packages?
[16:12] <pitti> kees: I put them all (including source.changes) to my people page
[16:12] <pitti> kees: it's a new orig.tar.gz, so if you want I can put an interdiff there?
[16:12] <kees> pitti: ah, yes, if you've got everything with source.changes, we can use that.
[16:12] <kees> no need for interdiff
[16:12] <pitti> kees: yep, all tested in their respective chroots, etc.
[16:12] <kees> excellent
[16:13] <pitti> kees: but I don't think I am actually allowed to upload to security-proposed, am I?
[16:17] <persia> pitti: I can't find the relevant wiki page just now, but somewhere around feisty, nomenclature was introduced to derivatives distinguishing "flavours", "remixes", and "derivatives": the first being entirely built as part of Ubuntu, the second being small unofficial changes or modifications (often used for LoCo releases, etc.), and the third being projects like Mint.  There's some fairly precise restrictions imposed on the level of variation to
[16:17] <persia>  qualify for each name.  If you are very curious, I'll try harder to find the wiki page tomorrow.
[16:17] <Keybuk> popey: videos from UDS are still being encoded and going up, right?
[16:17] <pitti> persia: ah, thanks for the heads-up!
[16:17] <pitti> persia: makes sense indeed
[16:18] <popey> Keybuk: i have requested some as the video crew didnt have time to do them all, asked if we could crowdsource the editing etc
[16:18] <Keybuk> popey: ah, I see; so there was a cut-off whereby if they didn't get it encoded during UDS, they didn't do it at all?
[16:19] <popey> i think so, yes
[16:19] <popey> elmo was the interface to the video people
[16:19] <elmo> no
[16:19] <persia> Note also there are official flavours (e.g. xubuntu) and unofficial flavours (e.g. sabily): the difference being that we're all supposed to care if we break the official ones (although it's nice to not break the unofficial ones)
[16:19] <slangasek> pitti, persia: right; I'm not sure if I ever read the wiki page, but I've intuitively tried to avoid referring to flavors as "derivatives" because the term implies they're secondary to Ubuntu desktop
[16:20] <elmo> what happened was, we asked the team leads to pick "the same number of sessions as Dallas" as that's what was budgeted for, and they helpfully picked 2x that amount
[16:21] <elmo> the as-yet-unedited stuff is being edited atm, and will go up when we get it.  we'll likely stop at the original 20-30 limit though, and if you guys want to 'crowdsource' the rest, that's obviously up to you
[16:21] <Keybuk> is there a way to know which sessions will be done and which won't?
[16:22] <Keybuk> just curious myself; i've found watching the videos back of my discussions very useful, especially in the wake of gobbygate
[16:22] <Keybuk> (not to mention very unnerving, my voice is much squeakier in real life than it sounds in my head - and apparently I can't stop moving)
[16:22] <elmo> Keybuk: i'm meant to be getting a list, I'll check on that
[16:23] <Chipzz> Keybuk: I got the same issue with my voice
[16:24] <Keybuk> elmo: thanks
[16:25] <popey> thanks for clarifying elmo
[17:19] <superm1> cjwatson, , sorry, no i don't.
[17:27] <kees> pitti: no, so really that bug needs ubuntu-security-sponsors sub'd to it.  I'll do that.
[17:28] <cyphermox> is it just me or now the trick of init=/bin/sh passed to the kernel no longer works for going straight to a shell? right now all I get is a system that stops after 'running /scripts/init-bottom'. what would be the new way of doing this?
[17:33] <joaopinto> cyphermox, it works for me on lucid, using /sbin/sulogin
[17:34] <cyphermox> ah, thanks, didn't think of that
[17:51] <dmart> kees: hi, were you just editing arm-m-missing-security-features?  I think some of our changes may have crossed over...
[17:56] <kees> dmart: I was, yes.  sorry if I clobbered something...
[17:56]  * kees checks
[17:56] <kees> dmart: hrm, I can't find a whiteboard history.  what changes did you make?
[17:57] <kees> dmart: ah-ha, I see it in email now...
[17:57] <dmart> kees: I think you undeleted some stuff on the whiteboard (it's duplicated on the wiki), and refined some of the actions.  I had a couple of actions, but they disappeared
[17:57] <dmart> (not that I mind my actions disappearing ;))
[17:58] <kees> dmart: hehe, no problem; I've extracted them from the email I just got on the update.
[17:58] <kees> dmart: how does it look now?
[17:58]  * dmart looks...
[17:59] <dmart> That looks OK.  I added the ": TODO" for each
[17:59] <kees> dmart: ah, yes.  thanks!
[18:00] <dmart> Should we include testing here too?  The spec template mentions test cases, and the sensible thing is probably for each assignee to come up with appropriate tests to make sure their features are working.
[18:00] <dmart> Probably x86 already has tests we can reuse for most of these.
[18:01] <kees> dmart: we can include it, but it's really "done" already.  I have a full test suite for each of those features.
[18:01] <kees> dmart: it's just a matter of removing the "if armel, XFAIL" checks.
[18:01] <dmart> OK, great :)  I'll tweak the wiki to indicate this
[18:01] <kees> dmart: cool.  I'll add a todo for me to adjust and run the testsuite
[18:02] <dmart> ok, sounds good
[18:03] <dmart> thanks
[18:20] <YokoZar> How do files installed into /usr/lib/python2.6/dist-packages end up there?  It looks like the packages say to install to /usr/lib/python2.6/site-packages
[18:24] <RoAk> YokoZar, python 2.6 has to install in dist-packages and not in site-packages
[18:25] <YokoZar> RoAk: that makes sense, but I dont' get how the packages are being moved.  Is it a maintainer script somewhere?  Eg: dpkg -S /usr/lib/python2.6/dist-packages/AptUrl  returns unknown, and looking at the apturl-common package it's supposed to install into /usr/lib/python2.6/site-packages
[18:26] <RoAk> YokoZar, I guess either python-central or python-support is doing that
[18:31] <RoAk> YokoZar, man dh_pycentral explains it
[18:32] <YokoZar> RoAk: thank you!
[18:32] <RoAk> np :)
[18:34] <smoser> looking for some help regarding debian/watch / uscan
[18:35] <smoser> at http://s3.amazonaws.com/ec2-downloads/ i want to watch for ec2-ami-tools-\d+\.\d+\-\d+.zip
[18:35] <smoser> but since there is no html to parse, i'm lost for how to tell uscan that
[18:38] <ccheney> smoser: perhaps email the devscripts devel team (see packages.qa.d.o) they might have to extend uscan to work with xml if it doesn't already work
[18:39] <smoser> yeah.. i'd guess its a big edge case
[18:39] <Pici> 50
[18:39] <ccheney> smoser: if its standard anyway, i'm not sure how xml pages like that are intended to work
[18:39] <smoser> yeah, i dont think there is any standard there.
[18:40] <smoser> realistically, they announce it somewhere else. they just dont
[18:45] <mdeslaur> mvo: I've added you to tasks in security-m-support-status and security-m-easier-security-updates blueprints. Feel free to reassign/complain/etc... :)
[18:47] <mdeslaur> seb128: I have some work items that I need to assign to someone...see the security-m-authentication-spoofing blueprint. Do you know who I should assign them to?
[18:48] <ccheney> smoser: i'm not sure but debian/rules get-orig-source may be what you want instead
[18:49] <ccheney> smoser: you can do anything you need inside that to grab the source, but its not uscan :-\
[18:49] <smoser> ccheney, thanks. i'll take a look.  i'm really hoping for the benefits of a watch file
[18:49] <seb128> mdeslaur, which items are those?
[18:50] <smoser> more than just downloading the original source , but i was unaware of get-orig-source rule
[18:50] <mdeslaur> seb128: it's to add the aboutme picture to the policykit and gksu password dialogs, and to make sure a random picture gets selected when a new user is created.
[18:51] <seb128> hum, patches are welcome? ;-)
[18:51] <seb128> mdeslaur, you want those to be assigned to somebody in the desktop team rather?
[18:51] <mdeslaur> seb128: uhm...yes? :)
[18:51] <seb128> mdeslaur, I'm not sure we want to sign up for extra work but I can check
[18:54] <mdeslaur> seb128: ok, thanks...let me know
[19:16] <pitti> Riddell: when you accept SRUs, can you please use sru-accept.py? (Please see https://wiki.ubuntu.com/StableReleaseUpdates#Reviewing%20procedure%20and%20tools)
[19:17] <ccheney> pitti: did you see my email from earlier?
[19:17] <pitti> ccheney: yes, I responsed to your IRC ping this morning
[19:17] <pitti> ccheney: I'm afraid the only thing that'll help is a rebuild, since the last build was longer than 7 days ago
[19:18] <ccheney> pitti: oh ok, seems my irc client ate it
[19:18] <seb128> mdeslaur, do you guy use work items for your specs?
[19:18] <ccheney> pitti: ok well i will be doing a proposed upload in a week or two once final 3.2.1 comes out, i think it will be fine until then
[19:18] <mdeslaur> seb128: yes, we do
[19:18] <micahg> pitti: out of curiosity are there any plans to get apport into Debian
[19:18] <pitti> ccheney: right
[19:19] <seb128> mdeslaur, ok, security-m-private-directory, the [actions] are wanted in that format? or should they be moved to items?
[19:19] <pitti> micahg: haven't heard of any; I don't think I'll have time to maintain everything there, it'd be a huuuge effort
[19:19] <pitti> micahg: (unless they want to use Launchpad for the crash reports and retracing, but even that will take a fair amount of work)
[19:19] <seb128> mdeslaur, sorry I asked after reading the email and there was not the whiteboard start there so I didn't notice you had work items on the spec too
[19:20] <mdeslaur> seb128: ah, ok :)
[19:20] <micahg> pitti: ok, we were wondering because if we increase the # of hooks, it would be good to push the hooks to Debian, but not all DM/DD will take since they;re useless in Debian ATM
[19:21] <micahg> pitti: but that's ok, thanks for the info
[19:22] <pitti> micahg: FYI, in udisks I do this: http://git.debian.org/?p=pkg-utopia/udisks.git;a=commitdiff;h=a9ddc5bb660a4f53c2533c8e154159dfcdd94519
[19:23] <micahg> pitti: that's perfect, would you mind if I added that to the docs once they are created?
[19:23] <pitti> micahg: alternatively, I'm not oppposed to having hooks for popular packages, where the hook is the only diff to debian, in apport-symptoms package
[19:24] <pitti> micahg: heh, of course not :)
[19:24] <micahg> pitti: great, thanks, I'll keep the apport-symptoms thing in mnd as well
[19:24] <micahg> *mind
[19:25] <micahg> pitti: is there a reason why you use lsb_release vs dpkg-vendor?
[19:27] <pitti> micahg: yes, this is the first time I hear about dpkg-vendor :)
[19:27] <micahg> pitti: ah, ok, I learned about it a couple months ago while doing a merge from Debian
[19:27] <pitti> dpkg-vendor --is Ubuntu, nice
[19:27] <pitti> micahg: this avoids the extra b-dep
[19:28] <micahg> pitti: ah, cool
[19:35] <fabrice_sp> pitti, may I have your opinion on bug #561958?
[19:35] <pitti> fabrice_sp: ah, I deliberately don't install this bit; it's crackful
[19:35] <pitti> it would need to use udisks or something
[19:36] <fabrice_sp> I see your comment in debian/rules, but without it, some readers are not recongnized
[19:37] <pitti> fabrice_sp: hm, will have a look later on; those readers are non-usb mass storage?
[19:38] <fabrice_sp> I think so, but I can check (mine is recognised as USB)
[19:45] <fabrice_sp> yeah: it seems that they are non-usb mass storage, so that would explain why without this program it does not work (nothing to mount)
[19:48] <mvo> mdeslaur: thanks, I noticed that - the amount of [mvo] in it is a bit disproportional to the amount of other names ;) but I will see what I can do, some of it should be really straightforward
[19:51] <mdeslaur> mvo: I didn't know who it should be assigned to, as I mentioned, feel free to reassign or to tell me what you can't/don't want to do
[19:51] <mdeslaur> mvo: btw, you're second in line for the cloning machine, right behind pitti
[19:51] <mvo> mdeslaur: heh :)
[20:44] <seb128> mdeslaur, hey again
[20:44] <seb128> mdeslaur, we don't have ressources for those this cycle
[20:45] <seb128> mdeslaur, if anybody want to work on that patches are welcome otherwise I guess it's not going to happen this cycle
[20:45] <seb128> mdeslaur, you can assign those to our team but it's likely we will not get to those
[20:45] <seb128> mdeslaur, otherwise your team might maybe try to work on those?
[20:46] <mdeslaur> seb128: okay, thanks
[20:46] <mdeslaur> seb128: we'll see what we can do
[20:46] <seb128> thanks
[20:46] <micahg> mdeslaur: I'd be happy to take care of the firefox packaging for installation if there's an example somewhere else
[20:47] <mdeslaur> micahg: ok, thanks
[21:34] <cody-somerville> Does it take awhile for requestsync to see new versions of a package in Debian?
[21:35] <cody-somerville> It thinks the version of a particular package is 17 when I'm looking at the accept message for version 18.
[21:35] <Laney> when was it uploaded?
[21:36] <cody-somerville> a few hours ago
[21:36] <Laney> probably takes longer than that for LP to learn about it
[21:36] <Laney> have a look at lp/debian/+source/package
[21:37] <Laney> however, if rmadison -u debian knows about it then requestsync from trunk will save you
[22:02] <cody-somerville> superm1, is the i8k module supported on vostro series laptops?
[22:41] <wgrant> Laney, cody-somerville: The Debian archive has been broken for a couple of weeks now, so the LP import is out of date.
[22:41] <wgrant> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577759
[22:41] <cody-somerville> ewww
[22:41] <wgrant> (this breaks debmirror for unstable)