[00:08] <bdrung> kees, SpamapS, slangasek: Please fix the debian revision of upstart with the next upload (bug #693630)
[00:11] <kees> bdrung: ah, yeah, will do.
[02:12] <ohsix> anyone know offhand the apt-fu or aptitude meta query for listing packages installed manually
[04:53] <pitti> Good morning
[04:53] <cyphermox> pitti,  good evening ;)
[04:53] <pitti> mtaylor: not right now, but please feel free to open a bug an subscribe me, and we discuss it there; sounds interesting
[04:53] <pitti> cyphermox: I can't sleep any more :)
[04:54] <cyphermox> pitti, I haven't gone to sleep yet ;)
[04:54] <cyphermox> it
[04:54] <cyphermox> it's still wednesday here :)
[04:54] <broder> pitti (and kklimonda): re our python-gtk discussion from a bit ago, andersk pointed out to me earlier today that you can do "import sys; reload(sys); sys.setdefaultencoding('undefined')"  :)
[04:55] <pitti> broder: hah, nice hack
[04:55] <mtaylor> pitti: cool. I'm trying to find a _sensible_ way to integrate i18n into openstack stuff
[07:03] <pitti> kees: please don't ask for testing -proposed packages; if you upload to -proposed, they need to be reviewed/accepted by ~ubuntu-sru first
[07:04] <pitti> and our sru-accept.py script will then do the call for testing
[07:15] <kees> pitti: oh! eek, sorry about that
[07:15] <pitti> kees: no problem, I'm processing the queues now
[07:15] <pitti> so it's not too much time in between
[07:15] <pitti> but lucid-proposed had been locked for a while for 10.04.2 prep
[07:15] <kees> pitti: yeah, sorry, I went from doing security-proposed -> -proposed bugs to normal -proposed bugs and got carried away.
[07:16] <kees> right.
[07:16] <pitti> kees: no problem; just mentioning it for next time
[07:16] <pitti> thanks for the sponsoring!
[07:16] <kees> you bet! thanks for looking through the queues.
[07:16]  * kees heads to bed
[07:16] <pitti> sleep well!
[07:38] <didrocks> good morning
[08:03] <didrocks> @pilot in
[08:04] <dholbach> good morning
[08:06] <didrocks> hey dholbach
[08:13] <pitti> james_w: since I merged the blueprints API patch, the linaro WIs have skyrocketed (they apparently were miscounted before), and I now get a lot of cron spam for "[WARNING] milestone "4.4-2010.07-0" is unknown/invalid"
[08:14] <pitti> james_w: do you actually need the linaro configuration on people.c.c. these days? you guys have your own instance now, don't you?
[08:15] <dholbach> lu didrocks
[08:15]  * dholbach hugs didrocks
[08:16]  * didrocks hugs dholbach
[08:18] <hyperair> is there a cross platform way of printing out '\n' in sh?
[08:18] <hyperair> in dash, echo -n '\n' dumps a newline to screen
[08:18] <hyperair> in other shells, you need -e for it to dump a newline
[08:18] <hyperair> so dash requires '\\n' to print out a literal \n, but in other shells, that comes out as \\n
[08:18]  * hyperair facepalms
[08:19] <hyperair> like for example, busybox's ash
[08:21] <RAOF> hyperair: /usr/bin/printf
[08:21] <hyperair> RAOF: hmm interesting.
[08:22] <hyperair> RAOF: thanks for the idea!
[08:22]  * hyperair goes about patching haserl
[08:39] <nigelb> persia: hi, around/
[08:39] <nigelb> persia: would you be interested in giving a session at UDW about talking to upstreams and debian in particular?
[09:37] <didrocks> mvo: in case you didn't notice, you have two waiting grammar typo fix in apt: https://code.launchpad.net/~evfool/apt/fix641673/+merge/48689 and https://code.launchpad.net/~evfool/apt/fix418552/+merge/48695
[09:38] <mvo> thanks didrocks
[09:38] <mvo> I noticed, but forgot already
[09:38]  * mvo points to https://launchpad.net/~blatant-and-awkward
[09:39] <didrocks> mvo: heh :)
[09:39] <nigelb> mvo: lol, nice team ;)
[09:40] <nigelb> cdbs: ping
[09:40] <nigelb> cdbs: Want to talk about somethign packaging-ish at Ubuntu Developer Week? :)
[09:46] <csurbhi1> mvo, ping
[09:50] <mvo> hey csurbhi1
[09:51] <csurbhi1> hey mvo!
[09:51] <csurbhi1> i wanted to verify something
[09:51] <csurbhi1> bug 693630
[09:52] <csurbhi1> i have marked that invalid.. because upstart is not based on any debian package..
[09:52] <csurbhi1> but wanted to make sure that sounds right
[09:52] <cdbs> nigelb: back
[09:53] <cdbs> nigelb: no, my exams are starting from March 2nd
[09:53] <cdbs> so I will be really busy
[09:53] <cdbs> and can't pull an hour out of my routine
[09:53] <mvo> csurbhi1: well, yes and no :) its correct, but debian is using a -X schema as well. so there is the risk of having two identical versions (includiing debian revisions) but with different content
[09:53] <nigelb> cdbs: yeah, sorry.  daniel told me later that he already asked you.
[09:53] <mvo> csurbhi1: so there is some value in still doing the -0ubuntu1 dance (or asking debian to do -1debian1)
[09:54] <csurbhi1> ok
[09:54] <csurbhi1> but would we ever take the debian package ?
[09:54] <mvo> csurbhi1: given that for us the change is minimal and it avoids confusion I would be inclined to just use -0ubuntu1
[09:54] <csurbhi1> to cause the confusion?
[09:54] <csurbhi1> i mean would not Ubuntu's upstart be upstream for Debian now?
[09:55] <csurbhi1> so that we dont take full patches from debian
[09:55] <csurbhi1> no?
[09:56] <csurbhi1> like the problem of collision will occur only in case of a merge sync?
[09:56] <mvo> that is true, we will most likely not take debian package but do our own, still it feels wrong to have two versions with the same number (including distro revision) that hae different content. IMO either we or debian should adjust the version
[09:56] <csurbhi1> merge request?
[09:56] <csurbhi1> mvo, ack
[09:56] <mvo> anytime people compare version numbers
[09:56] <csurbhi1> thanks!
[09:57] <csurbhi1> ok, i will update the bug once again then :) and update it with your comments
[09:57] <mvo> yw, I think while technically its correct that we have -X for practical reasons we should adept
[09:57] <mvo> (or ask debian nicely to do that)
[09:58] <csurbhi1> one query
[09:58] <csurbhi1> i still have
[09:58] <csurbhi1> when we take debian's vanilla package
[09:58] <csurbhi1> and have no patch to add on top of it
[09:59] <csurbhi1> we do not have the -0ubuntuX scheme
[09:59] <csurbhi1> right?
[09:59] <mvo> csurbhi1: yeah, if we just sync it, we keep the version number from debian
[09:59] <csurbhi1> i mean if its not a merge request?
[09:59] <csurbhi1> ok
[09:59] <mvo> (as the source is the same)
[09:59] <csurbhi1> would debian be doing that with Ubuntu's upstart?
[10:00] <csurbhi1> owing to which the version numbers are the same?
[10:01] <mvo> csurbhi1: I think it would be a good idea if debian merges from ubuntu to have -1debian1 for example
[10:01] <mvo> csurbhi1: but I don#t think there is a policy for this yet
[10:01] <mvo> (in debina)
[10:02] <csurbhi1> just being a devils advocate here... but in the case the source is the same, Ubuntu can then have the same version number right :)
[10:02] <csurbhi1> but i get the gist of it..
[10:02] <csurbhi1> i will update the bug.. thanks for the enlightenment
[10:14] <janimo> what is the differnece between ubuntu.natty and platform.natty seeds?
[10:15]  * janimo wishes LP branches made use of the optional description field
[10:19] <mvo> csurbhi1: your welcome :) (sorry for the delay, was on the phone)
[10:19] <csurbhi1> mvo, np
[10:19] <cdbs> mvo: hi, do you intend to restrict the ability to review an app in s-c only for those who have installed it?
[10:20] <cdbs> (similar to the way iOS App Store and Android Market do)
[10:20] <mvo> cdbs: hello! iirc that is what the spec says, so yeah :)
[10:52] <bankix> Hi.
[10:56] <didrocks> session restart, brb
[10:59] <chrisccoulson> who's going to take care of gjs in the archive?
[11:00] <chrisccoulson> libmozjs is currently breaks ABI with every single point release....
[11:00] <chrisccoulson> s/breaks/breaking/
[11:00] <chrisccoulson> we dropped it for a reason
[11:05] <didrocks> chrisccoulson: bigon will
[11:06] <didrocks> chrisccoulson: I checked with him at fosdem and as he maintains it in debian and ubuntu, he'll follow the ABI breakage
[11:06] <didrocks> chrisccoulson: btw, the reason on the drop was just "unused by default", the ABI breakage should have been mentionned
[11:06] <chrisccoulson> right
[11:06] <chrisccoulson> but it's still unused isn't it?
[11:07] <didrocks> chrisccoulson: yeah, but people developping on ubuntu like the telepathy guys needs it for their dev
[11:07] <didrocks> I think it's not an isolated case
[11:39] <cjwatson> janimo: platform.natty => seeds common to all products; ubuntu.natty => seeds for Ubuntu desktop and server editions
[11:46] <janimo> cjwatson, thanks.
[11:46] <dholbach> who of you has started working on a small project that you want to introduce and get people interested in? we are going to have a "project lightning talks" in the last session of UDW: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Sessions - feel free to sign up
[12:00] <blackmoon105> is possible to report a bug for "ubuntu-wine" ppa package? i can only report a bug for official wine version...
[12:00] <nigelb> PPA bugs aren't yet available
[12:00] <nigelb> you'll have to contact the author
[12:00] <blackmoon105> nigelb: ok, thank you!
[12:01] <nigelb> blackmoon105: :)
[12:13] <dholbach> fabbione, happy birthday! :)
[12:13] <fabbione> dholbach: thanks man :)
[12:26] <blackmoon105> hi, how can i be a official mantainer (not ppa) of a ubuntu package? so i can keep it update with the latest version..
[12:27] <dholbach> blackmoon105, get a new versioned sponsored into Ubuntu (https://wiki.ubuntu.com/SponsorshipProcess), after you've worked with a few sponsors, apply for upload rights (https://wiki.ubuntu.com/UbuntuDevelopers)
[12:32] <blackmoon105> dholbach: thanks, i read it
[12:46] <didrocks> @pilot out
[12:50] <dholbach> didrocks, great work!
[12:51] <didrocks> dholbach: thanks, hope that help the queue a little :)
[12:51] <dholbach> good job! :)
[13:22] <Daviey> JamesPage, Is mvel on your radar for a merge?  It's really out of date... we haven't merged since at least karmic by the looks of it; and it's a major version increase.
[13:23] <Daviey> JamesPage, I don't mind having a stab of it.
[13:24] <jfer> hi, i was wondering if there were plans to add MariaDB to the ubuntu repository?
[13:24] <Daviey> JamesPage,  hmm.. seems it was never sync'd - it was a ubuntu native package which is now in Debian
[13:26] <cdbs> mvo: ping
[13:27] <mvo> pong cdbs
[13:27] <Daviey> jfer, The logical step is for it to enter Debian and be sync'd across.. Inclusion in Debian is being tracked @ http://bugs.debian.org/565308
[13:27] <cdbs> mvo: hi, https://code.launchpad.net/~bilalakhtar/software-center/write-review-installed-only/+merge/49206 read the two comments, what do you say about this? should a bug be filed? on what? ayatana-design?
[13:27] <mvo> cdbs: I have a look now, many thanks
[13:28] <jfer> ok thanks Daviey
[13:29] <jfer> so it won't make it into natty then?
[13:29] <Daviey> jfer, hmm.. looking at the progress of that i would say it's possible but unlikely.
[13:32] <jfer> ok it seems that the conflict with MySQL is the main reason for the delay
[13:40] <JamesPage> Daviey: OK so we currently have two mvel packages - one in main (mvel) and one in universe (mvel2)
[13:41] <JamesPage> Daviey: mvel2 build-deps on Maven (not in main); we could potentially converge the packages but not without major MIR work for Maven-> main
[13:41] <james_w> pitti, yeah, let's delete the linaro config from your instance. We do indeed have our own instance.
[13:41] <Daviey> JamesPage, *sigh* :)
[13:41] <james_w> pitti, let me know if that isn't enough and I'll propose a patch to handle whatever is left.
[13:42] <pitti> james_w: thanks; I commented out the linaro teams from natty.cfg now
[13:42] <Daviey> JamesPage, Sounds like something to revist next cycle
[13:42] <JamesPage> Daviey: whats the requirement for it at this point in time?  I'm starting to see a number of packages in Debian switch from Ant to Maven which are already in main so its going to get worse....
[13:42] <pitti> james_w: there are still the separate linaro reports, of course (http://people.canonical.com/~platform/workitems/linaro-multimedia-wg/all.html etc.)
[13:43] <james_w> pitti, thanks
[13:43] <Daviey> JamesPage, i just noticed there versions were significantly different... it doesn't gain us anything i don't think having a newer thing... we need to maintain the version in Lucid regardless, so lets pin
[13:44] <JamesPage> Daviey: OK - I'm going to spec Maven -> Main for UDS-O so next cycle then (well maybe :-)
[13:45] <Daviey> JamesPage, I don't think users have complained that it's an old version, and with the major new version in universe already.. seems we are currently in a  good position
[13:45] <Daviey> JamesPage, You've been looking for more excuses to get Maven promoted to main, haven't you? :)
[13:45] <JamesPage> Daviey: TBH it just means that we are having to maintain a larger Ubuntu delta over debian than we should be for some areas of the Java library
[13:46] <JamesPage> Daviey: and yes I have :-)
[13:47] <Daviey> heh
[13:49] <mvo> thanks cdbs, branch looks fine
[13:51] <cdbs> mvo: Did you read the comment by Aaron?
[13:51] <cdbs> That ain't a bad idea
[13:53] <mvo> cdbs: true
[13:58] <cdbs> mvo: okay, if you find fit you may merge this branch for now, in the meantime, I will file a bug and look for mpt feedback
[13:59] <cdbs> bug about asking the user to review before uninstalling
[14:01] <mvo> cdbs: it appears the spec has it, its just a bit hidden
[14:01] <cdbs> mvo: it does?
[14:02] <mvo> """"This process begins when you activate the “Review…” button on an “Installed Software” item screen."""
[14:02] <mvo> https://wiki.ubuntu.com/SoftwareCenter/RatingsAndReviews
[14:03] <cdbs> mvo: I know that. I mean that the thing that the user should be prompted to review an app when uninstalling it, isn't in the spec
[14:03] <mvo> cdbs: aha, indeed
[14:03] <cdbs> mvo: just filed bug #716435
[14:04] <cdbs> mvo: so, that branch may be fit to go in now, I will work on this bug when the design spec is having that
[14:04] <cdbs> mvo: okay, I g2g now, bye!
[14:04]  * cdbs /aways
[14:47] <janimo> pitti, would jockey be a suitable component to handle some aspects of bootloader file updates on ARM? These are blobs which are packaged in Ubuntu, but need to be installed elsewhere not on /, such as copied to a vfat partition
[14:48] <janimo> pitti, there is a spec that deals with allowing users to update their bootlaoders easily and safely at least on the supported ARM images which keep their bootloaders on SD card's first partition
[14:49] <joaopinto> hello
[14:50] <Laney> there's a bot to do that ;-)
[14:51] <kenvandine> whoops
[14:51] <joaopinto> is it known that Natty's grub sets an unusable text mode with certain gfx cards/displays ?
[14:51] <kenvandine> @pilot in
[14:52] <soren> Is there a trick to get rid of the invisible window in the upper left corner that prevents me from clicking on things in unity? I thought that had been fixed, but I'm seeing it now.
[14:53] <cjwatson> joaopinto: https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032244.html
[14:53] <cjwatson> joaopinto: https://wiki.ubuntu.com/FoundationsTeam/Grub2BootFramebuffer/Whiteboard
[14:55] <soren> Uh... Weird. Turned out it was a crashed gvim. xkill took care of it.
[14:55] <joaopinto> cjwatson, the mail is not very clear in what related to the menu, it mentions transition, my issue is with the menu presentation, not with the transition itself
[14:56] <seb128> soren, usual workaround is to restart compiz or smspillaz said to hide and show the desktop can workaround it as well
[14:56] <cjwatson> joaopinto: the whiteboard has one entry on it which may be your problem
[14:56] <cjwatson> "Corrupted video in GRUB"
[14:56] <seb128> soren, i.e ctrl-alt-d twice
[14:56] <joaopinto> ok, checking
[14:57] <joaopinto> oh, ThinkPad, it's me :P
[14:57] <soren> seb128: Ah, cool.
[14:57] <soren> seb128: Thanks.
[14:58] <seb128> soren, yw, btw smspillaz is working on that bug and said it will probably be fixed by end of the day
[14:58] <seb128> let's see
[14:58] <soren> \o/
[15:00] <artfwo> seb128, don't you have a link to the bug by chance?
[15:01] <seb128> bug #709461
[15:02] <artfwo> thanks!
[15:06] <micahg> kenvandine: can you look at bug 713492, I believe there might be a symbols issue, so I wasn't comfortable sponsoring
[15:07] <kenvandine> micahg, sure
[15:08] <micahg> kenvandine: thanks
[15:13] <blackmoon-105> i've run "  apt-cache show freepops | grep ^Source: | sort -u | cut -d: -f2- " but it don' result nothing..
[15:14] <persia> blackmoon-105, That happens when the source name is the same as the binary name.
[15:14] <persia> You might find `apt-cache showsrc ...` useful
[15:14] <blackmoon-105> persia: thanks
[15:16] <blackmoon-105> persia: blank output also with 'showsrc'
[15:17] <persia> If you put it through the same pipes, that's expected.
[15:22] <blackmoon-105> persia: ok, i've found that i don't have the "Source:" entry.. and so greo don't find it..
[15:22] <blackmoon-105> *greo --> grep
[15:23] <persia> Right.  showsrc shows the source for Package, and lists binaries.  show shows the binary for Package, and sometimes lists source.
[15:27] <Riddell> cjwatson: I split kubuntu-mobile into a separate seed collection, can you remind me the right way to make changes to ubuntu-cdimage and its bzr archive?
[15:31] <cjwatson> Riddell: bzr co bzr+ssh://antimony/srv/cdimage.ubuntu.com/bzr/cdimage/  on your laptop, make changes there, commit - then let me know
[15:31] <blackmoon-105> persia: ok, thank you
[15:32] <cjwatson> blackmoon-105: you might also like to install dctrl-tools and learn to use grep-dctrl, if you're going to be doing lots of this
[15:33] <blackmoon-105> cjwatson: done, i do it
[15:33] <cjwatson> blackmoon-105: e.g.:  apt-cache showsrc freepops | grep-dctrl -nsSource:Package ''
[15:33] <cjwatson> (maybe sort -u in there too)
[15:34] <blackmoon-105> cjwatson: good, i've got the desired output
[15:48] <blackmoon-105> bzr log -l 1 lp:ubuntu/maverick/sysvinit | grep ^tags: | cut -d: -f2-  give me an "Permission denied (publickey)" eror, it's because i'm not the owner of repo?
[15:54] <nigelb> kirkland: ping?
[15:56] <kirkland> nigelb: pong
[15:56] <nigelb> kirkland: hey, want to talk about one of your projects at projects lightning talk for UDW?
[15:57] <nigelb> kirkland: We're trying to give 5 minutes per project to say what it does, how it can be used, and how you could use help :)
[15:58] <nigelb> kirkland: (I personally was thinking of bikeshed hearing about bikeshed and the kind of cool stuff it has)
[15:59] <kirkland> nigelb: sure
[15:59] <cjwatson> blackmoon-105: no, you should be able to 'bzr log' any public branch
[15:59] <kirkland> nigelb: i can talk about any of them
[15:59] <nigelb> kirkland: great! I'll put you down for a session :)
[15:59] <kirkland> nigelb: it's just 5 minutes, right?
[15:59] <cjwatson> blackmoon-105: follow the "one-time setup tasks" listed in https://help.launchpad.net/Code/QuickStart#Push%20a%20Bazaar%20branch%20to%20your%20project
[15:59] <nigelb> kirkland: yup 5 minutes
[15:59] <kirkland> nigelb: sure, you bet
[15:59] <cjwatson> (that goes on to talk about running 'bzr push' - I know you don't need to do that)
[15:59] <blackmoon-105> cjwatson: ok, now i check
[15:59] <kirkland> nigelb: i can introduce a handful of the most useful ones
[15:59] <nigelb> kirkland: awesome, that's great :)
[16:00] <kirkland> nigelb: what's the date?
[16:00] <kirkland> nigelb: and time?
[16:01] <nigelb> kirkland: friday 4th march at 20:00
[16:01] <kirkland> nigelb: hmm, okay
[16:01] <kirkland> nigelb: that might be tough
[16:02] <kirkland> nigelb: is that UTC?
[16:02] <nigelb> kirkland: yup UTC
[16:02] <kirkland> nigelb: okay, worst worst worst case, can I type up a script of what I would say, email it to you, and you paste it on my behalf, in case I can't make it?
[16:03] <nigelb> kirkland: worst case, yes, I can do that for you :)
[16:03] <kirkland> nigelb: thanks
[16:03] <nigelb> kirkland: thank you for joining the party :D
[16:03] <kirkland> nigelb: i'm going to be traveling that day, which is my only concern
[16:03] <kirkland> nigelb: but i'm happy to help :-)
[16:04] <nigelb> kirkland: :-)
[16:18] <kklimonda> hmm.. how to check what is sending out a lot of data?
[16:18] <kklimonda> who, u1
[16:20] <joaopinto> cjwatson, about the "Corrupted videon in GRUB" on thinkpads, is there some something I can do to to help, or you have enough triage already ?
[16:26] <ev> is there not an ICS or google calendar URL for the release schedule anymore?
[16:33] <micahg> kenvandine: so the warning of the lack of a symbols file wasn't relevant to the ccscript update?
[16:36] <kenvandine> micahg, i don't think so, but i am suggesting they add a symbols file in the future, currently no worse than before
[16:37] <micahg> kenvandine: ah, ok
[17:14] <Riddell> cjwatson: cdimage committed
[17:31] <barry> jam: very interesting.  y'know the udd page on working with a patch system?  well, i am hacking on numpy and i did not need the final quilt push/quilt pop this time.  in fact, it caused some recoverable problems.
[17:31] <jam> barry: so if you had *not* done the push/pop you would have been ok?
[17:31] <barry> jam: in this case, yes
[17:32] <barry> it was *definitely* needed the last time i hacked on a quilt3 package thoug, so really i have nfc ;)
[17:32] <jam> so *my* understanding of V3 quilt, is that the changes are supposed to be in the working tree (pushed?)
[17:32] <barry> jam: i think that's the effect of what i'm left with.  i'm about to push the branch so you can take a look
[17:32] <cjwatson> push/pop should just try to apply the patch and then back it out again.  it would catch corrupt-patch kinds of problems.
[17:32] <jam> versus pre v3 packaging, where the patches were supposed to only be in debian and not in the wt
[17:33] <jam> barry: were was the actual failure? in the upload?
[17:33] <cjwatson> one of the fundamental ideas of 3.0 (quilt) packaging is that when you do dpkg-source -x you should get the patches applied, rather than relying on debian/rules to do it for you
[17:33] <cjwatson> what you think the working tree representation should be depends on whether you think the wt should be basically equivalent to dpkg-source -x
[17:34] <cjwatson> my take is that it should be but apparently this isn't universal
[17:34] <barry> cjwatson, jam: when i do the quilt push, i get patch hunk failures.  presumably because it is trying to re-apply the patch to an already patched source tree.  which makes sense, but doesn't explain why i had to do it before
[17:35] <cjwatson> barry: so the patch really ought to be pushed but quilt just doesn't know it?  in that case, http://people.canonical.com/~cjwatson/dpkg-quilt-setup
[17:35] <cjwatson> barry: and see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204
[17:35] <jam> cjwatson: well, as I don't know anything about dpkg-source -x ... :)
[17:35] <cjwatson> jam: the one and only canonical way to unpack a Debian-format source package
[17:36] <jam> cjwatson: except all of the other things above it that may do something differently? as I've never run that command, but have run "apt-get source" many times
[17:36] <cjwatson> jam: apt-get source calls dpkg-source -x .
[17:36] <cjwatson> I don't know of any software in the archive that doesn't use dpkg-source -x to unpack source packages
[17:36] <cjwatson> and all that apt-get source does in addition is to deal with acquiring the source package
[17:37] <cjwatson> it doesn't do any extra tree mangling
[17:37] <jam> cjwatson: good to know
[17:37] <cjwatson> I suspect barry's problem is an instance of the general problem of .pc getting out of sync with the base of the patch stack; which is something udd could (theoretically ...) help with
[17:37] <barry> cjwatson: what i think is happening is this: the source includes the fix because that's where i hacked.  then the 'quilt import' does the right thing, and all you need is to bzr add the new debian/patches file and commit.
[17:37] <jam> barry: the other question, how do you *tell* quilt that the patch is already implied?
[17:37] <jam> is there something you should be running other than "import"?
[17:37] <cjwatson> jam: see above, dpkg-quilt-setup
[17:38] <cjwatson> but that's not official or anything
[17:38] <cjwatson> let me finish my disquisition on .pc and then it may be clear :-)
[17:38] <cjwatson> the files under .pc/PATCH, for each PATCH in the series, are copies of the clean state of each file that's part of PATCH before PATCH was applied
[17:38] <jam> cjwatson: so your script backs out all current patches, and then patches back from the beginning
[17:38] <jam> I'm pretty sure barry just wants to add one at the end
[17:38] <jam> with the current diff content
[17:39] <cjwatson> let me finish
[17:39] <cjwatson> please
[17:39] <cjwatson> it will be easier :)
[17:39] <jam> k
[17:39] <cjwatson> when you do something like an upstream merge, that conceptually changes the base state under the patches in your queue
[17:39] <barry> cjwatson: that's plausible.  if the package importer somehow messed up the .pc directory (which is under vcs), then it's possible the previous package i sworked on required that becuase it was out of sync, but numpy does not because it is in sync
[17:39] <cjwatson> I'm mangling terms a bit but hopefully YKWIM
[17:40] <cjwatson> .pc has to be kept in sync with the unpatched states of files or else quilt will get confused and all sorts of things will go disastrously wrong
[17:41] <cjwatson> dpkg-quilt-setup is a brute-force "assuming that all the patches are valid, get everything back in sync with a big hammer"
[17:41] <jam> cjwatson: there are 2 things at play, I think your problem is indeed a real one, but not what barry is hitting.
[17:41] <cjwatson> however it's mostly useful when you're checking out a tree that doesn't have .pc in it (because checking in .pc tends to produce large numbers of confusing diffs when you commit)
[17:41] <jam> barry's is "I just did some hacking, add the new changes to the quilt"
[17:42] <cjwatson> jam: if he's getting a 'quilt push' failure, it must mean that his series and the quilt state under .pc are out of sync
[17:42] <cjwatson> there's no other way for that to happen
[17:42] <jam> cjwatson: he just did an import, would that put it out of state?
[17:42] <jam> or is quilt supposed to see that the patch is already applied
[17:42] <jam> and just ignore the push?
[17:42] <cjwatson>        import [-p num] [-R] [-P patch] [-f] [-d {o|a|n}] patchfile ...
[17:42] <cjwatson>            Import external patches.  The patches will be inserted following the current top patch, and must be pushed after import to apply them.
[17:43] <jam> right, they are *already* applied
[17:43] <jam> he just used "bzr diff -rlast_state | quilt import"
[17:43] <cjwatson> oh yeesh
[17:43] <jam> he could then do "bzr revert -r last_start; quilt push"
[17:43] <cjwatson> redesign time :)
[17:43] <barry> jam: exactly right
[17:43] <cjwatson> I wouldn't do it that way
[17:44] <cjwatson> I'm trying to think of how I would do it
[17:44] <barry> cjwatson: here are the current instructions: https://wiki.ubuntu.com/DistributedDevelopment/Documentation/PatchSystem
[17:44] <cjwatson> actually, frankly, I just do it all in quilt to start with and it is much easier, but I'm assuming that you have sort of ideological reasons not to do that
[17:45] <barry> cjwatson: hacking the source until you're happy and then diffing to an import is so tempting, convenient, and natural
[17:45] <cjwatson> you could hack the source inside a 'quilt shell'
[17:45]  * persia notes that the expected final state of the source package differs between Format: 1.0 packages using quilt, and Format: 3.0 (quilt) packages, which may affect the UDD documentation.
[17:46] <cjwatson> a cleaner approach might be to revert *first* and then import
[17:46] <cjwatson> then you will get a clean push
[17:46] <cjwatson> since import is intended for importing an external patch that isn't applied to your tree yet
[17:46] <cjwatson> if you follow that then you'll get minimal impedance mismatch
[17:47] <cjwatson> (I actually use fold instead of import since I find that model slightly less confusing, but whatever)
[17:47] <jam> cjwatson: what is fold?
[17:47] <jam> barry is trying to document the way to do some of this
[17:47] <jam> it would be good to update that part
[17:47] <barry> persia: ack.  i would be ecstatic if we could start with figuring out the right way to do quilt3 ;)
[17:47] <cjwatson> import creates a new patch and applies stuff in one go
[17:48] <cjwatson> fold applies stuff to the patch that's on the top of the stack
[17:48] <jam> cjwatson: so you would create a new patch on the stack, but empty
[17:48] <jam> then fold the current changes into it?
[17:48] <cjwatson> I personally find it less confusing to decompose those two operations, so I do 'quilt new name-of-patch.patch' and then 'quilt fold -p1 <external-patch'
[17:48] <cjwatson> then 'quilt refresh', and now my tree is in sync with the patch applied
[17:48] <cjwatson> and I can go fill in DEP-3 headers
[17:48] <barry> cjwatson: right.  last time i used fold though, it gave me unresolvable conflicts
[17:49] <cjwatson> that would be a "using it in the wrong context" problem :)
[17:49] <barry> :)
[17:49] <cjwatson> (I'm not at all arguing that this doesn't need some kind of wrapping up)
[17:49] <cjwatson> but fold if used correctly doesn't produce conflicts - I use it all the time
[17:49] <jam> cjwatson: I think some sort of "bzr export-to-quilt -rX..Y patch-name" is probably what we want
[17:49] <cjwatson> I agree
[17:50] <jam> but I have to actually understand quilt before I could write something like that
[17:50] <barry> jam: +1
[17:50] <jam> cjwatson: also, in my ideal udd scenario, the patches would all be in a loom that we can merge properly, and then we only export the loom to a quilt as a "and let debian see this too"
[17:51] <cjwatson> sure, with the proviso that the headers in patch files are actually useful and need to be editable
[17:51] <jam> so while I want tools to make it integrate nicely, I also don't want to spend a lot of time getting to where we want to be
[17:51] <jam> cjwatson: also something that I need either to be documented or internalized. What is in there, and what belongs in there?
[17:51] <cjwatson> http://dep.debian.net/deps/dep3/
[17:51] <cjwatson> it can reasonably be considered as "description of this thread in the loom"
[17:52] <persia> Some of that can probably be sensibly defaulted from the metainformation bzr already has.
[17:52] <cjwatson> not all of it
[17:52] <jam> persia: the problem is being a simple summary
[17:52] <jam> we could probably populate one by guessing
[17:52] <cjwatson> and TBH I think trying to do that would be a distraction
[17:52] <jam> but ultimately it is like debian/changelog
[17:52] <jam> people want to summarize what is 20-some odd commits into a simple statement
[17:52] <jam> and mutate that in the future as clarifications arise
[17:53] <cjwatson> right, exactly
[17:53] <barry> note that you do have the commit message
[17:53] <cjwatson> the commit message really isn't enough
[17:53] <cjwatson> have a look at openssh
[17:53] <jam> barry: the problem is that you have 20 commit messages
[17:53] <jam> and none are a summary
[17:53] <cjwatson> lots of those patches are long-lived
[17:53] <cjwatson> and go through multiple commits on merges, emendations, etc.
[17:53] <barry> yeah, i suppose so
[17:53] <jam> a final merge-commit *could* be a summary, but I'm not sure how you want to rollup that over time.
[17:53] <barry> export-to-quilt could take a -m
[17:54] <cjwatson> you don't want it to be something you just type in at export time
[17:54] <cjwatson> the summaries include things like justifications for why the patch is carried despite not being upstream
[17:54] <persia> Manual editing of the DEP-3 header isn't that bad, and it's not worth fussing about that yet.
[17:54] <jam> barry: the issue is "convert-loom-to-quilt" needs to track all the -m's you've supplied over time.
[17:54] <cjwatson> this is genuinely long-lived data
[17:55] <jam> persia: sure. but in a "we don't want to have debian/patches or .pc until we are finally done" determining where to put it is important
[17:55] <barry> persia: you're right.  my only issue is that it's another step that you have to remember, rather than the tools helping you remember ;)
[17:55] <jam> we don't want debian/patches because they are mostly redundant with the wt state
[17:55] <cjwatson> frex, http://patch-tracker.debian.org/patch/series/view/openssh/1:5.6p1-2/gssapi.patch
[17:55] <jam> except for stuff like dep3
[17:55] <persia> jam, You'll often start with debian/patches though.
[17:55] <jam> persia: ideally in a fully udd world (which is what this channel is about), we'd get away from them
[17:56] <jam> but yes, at some point that needs to be imported
[17:56] <jam> and at some point exported
[17:56] <cjwatson> wait, this channel is #ubuntu-devel, not #udd-devel :-)
[17:56] <jam> so the intermediate form needs to have a way to track it
[17:56] <jam> cjwatson: ah, I'm in the wrong one :)
[17:56] <jam> :)
[17:56] <persia> "this channel"?  I'm not sure about that.  In a fully-UDD world, we'd want a different implementation of Format 3.0 (bzr), and some source-format conversion tools.
[17:56] <cjwatson> this channel has to deal with interaction with Debian, and thus isn't going to get away from debian/patches/
[17:56] <barry> from __future__ import udd_dev as ubuntu_dev
[17:57] <jam> cjwatson: I just looked at the channel topic, is dapper still supported?
[17:57] <cjwatson> yes
[17:57] <cjwatson> it goes out of server support in June
[17:58] <jam> I was curious about that, and thought it had happened earlier. I guess that was desktop support
[17:58] <barry> well, the good news is that i think i have a decent workaround for bug 664276 if i can express it correctly ;)
[17:58] <cjwatson> desktop support ended in June 2009, yes
[17:59] <jam> barry:  now is that numb-pie or numpy like lumpy :)
[18:00] <barry> jam: depends on who you ask.  yooboontoo or ewboontoo?  lynn-uhx or lie-nux?  tomato or ... :)
[18:01] <jam> tomato
[18:01] <jam> sure
[18:01] <jam> I've always said numb-pie. I only just now saw it as lumpy
[18:02] <mok0> jam, I've always said "nubm-pie" but I will now start saying "numpi" :-)
[18:02] <barry> anyway, cjwatson, jam, persia thanks for the good discussion.  if you have insight into how you think this *should* work, please do post to the udd list.  i've mostly just documented what kindof-sortof-doesmostly-work
[18:03] <barry> i've always said numb-pie too, but in a kind of homer simpson "mmm! floor-pie" voice
[18:03] <jam> barry: with a little drool after it. sounds good
[18:03] <barry> :)
[18:04] <mok0> barry:  we should all start saying "numb-bee" in an Abu-kind of way ;-)
[18:05] <barry> mok0: :)
[18:06] <barry> cjwatson, persia: in dep3, should <Vendor> in Bug-<Vendor> be Launchpad or Ubuntu?
[18:06] <cjwatson> Ubuntu
[18:06] <barry> cjwatson: thanks
[18:06] <cjwatson> well, bugs.launchpad.net/ubuntu is Ubuntu
[18:06] <cjwatson> bugs.launchpad.net/<upstream> is probably just Bug:
[18:07] <barry> cjwatson: nod
[18:07] <persia> And as Launchpad develops greater support for more distributions, the answer gets more complex
[18:07] <ari-tczew> Bug: https://launchpad.net/bugs/XXXXXX
[18:07] <ari-tczew> shorter ;-)
[18:07] <persia> That's not actually helpful in this context, as it doesn't embed the string to use for Vendor
[18:07] <barry> ari-tczew: Bug-Ubuntu: though, right?
[18:07] <ari-tczew> barry: if launchpad is not bug tracker for upstream, right
[18:08] <cjwatson> ari-tczew: sure, I just meant what the canonical target for the redirection was
[18:08] <cjwatson> rather than the value of the field
[18:08] <jam> ari-tczew: http://pad.lv/XXXX even shorter
[18:09] <ari-tczew> jam: quite unnatural
[18:09] <persia> jam, Yes, but not as helpful, as it doesn't identify the source in a way easily understood by as many folk, meaning that it's trickier to integrate into other tools.
[18:09] <jam> persia: I wasn't saying you should put it into official history, just saying it is a nice shorthand to get to any lp bug
[18:10] <persia> Oh, sure.  I use http://deb.at/L#### myself, just because I find the variety of deb.at redirects helpful.
[18:10] <cjwatson> Riddell: deployed
[18:11] <barry> ari-tczew: right.  in this case, it's a purely ubuntu bug
[18:46] <kenvandine> @pilot out
[20:11] <chrisccoulson> does anyone know why all the armel builders are offline?
[20:12] <ogra> chrisccoulson, lamont i suppose
[20:13] <ogra> (he owns them)
[20:13] <chrisccoulson> thanks
[20:14] <lamont> chrisccoulson: the switch they're behind had some work done on it, and then I got back from lunch...
[20:15] <chrisccoulson> lamont, cool, thanks
[20:30] <mvo> cjwatson: btrfs alternate install works like a charm!
[20:30] <mvo> (just fyi)
[20:31] <cjwatson> mvo: yay
[23:22] <bankix> Good morning.
[23:22] <bankix> I need some help building my own kernel package for ubuntu.
[23:23] <bankix> I need a patch within my kernel and would build a new package with usual package name.
[23:24] <bankix> E.g. linux-image-2.6.32-28-ctbankix1
[23:24] <achiang> bankix: #ubuntu-kernel might be better for your question
[23:24] <bankix> Ah, good point, thanks.