[01:13] <robert_ancell> how do I find why a package has been removed from the archive?
[01:15] <ajmitch> the publishing history on launchpad should show a reason
[01:16] <ajmitch> there should be a link in the top-right of the page for the package
[01:36] <robert_ancell> ajmitch, cheers!  screenruler is gone.  I used that a lot...
[01:37] <ajmitch> looks like it needed a bit of love
[01:48] <ScottK> I guess you'd have to love it enough to port it to Gnome 3.
[01:49] <ajmitch> & you'd need to love ruby, I don't know what the state of the bindings are there
[01:54] <ScottK> Oddly enough, I just uploaded updated Qt and KDE bindings for Ruby.
[04:37] <pitti> Good morning
[04:37] <ajmitch> morning pitti
[04:38] <pitti> bdmurray: I think we can add the complete Ubuntu revision in the ubuntu hook, as we often have ubuntu revision specific changes
[04:38] <pitti> hey ajmitch, how are you?
[04:41] <ajmitch> pitti: I'm good, how are you today?
[04:41] <pitti> ajmitch: very good, thanks!
[05:39] <didrocks> good morning
[05:43] <didrocks> @pilot in
[07:09] <dholbach> good morning
[07:12] <sladen> Morgen Damen und Herren!
[07:38] <OdyX> is persia usually around ?
[07:41] <tumbleweed> OdyX: he's not been around for the last month
[07:41] <geser> OdyX: I didn't see him for some time now, I don't know if there a better way to reach him
[07:42] <tumbleweed> word is he's due back some tmie soon
[07:42] <OdyX> okay. I'll do without his feedback for my DC11 report then.
[07:59] <dholbach> smb`, happy birthday
[08:35] <doko_> Sweetshark, should that be removed? if yes, please leave a comment. https://bugs.launchpad.net/ubuntu/+source/ooo-build-extensions/+bug/755987
[09:54] <didrocks> @pilot out
[10:10] <dholbach> didrocks, good work
[10:10] <seb128> dholbach, can we move the importer bugs to another list? ;-)
[10:11] <seb128> dholbach, that's really spamming the sponsoring queue for things which are not sponsoring
[10:11] <didrocks> dholbach: thanks :)
[10:11] <dholbach> bdrung_, tumbleweed: ^ what do you think?
[10:11] <cjwatson> agreed, that would be a good idea
[10:12] <didrocks> yeah, I just cleaned the obvious noise one, to let "real issues for investigation" for udd people
[10:12] <didrocks> but it's quite noisy in the list
[10:12] <seb128> didrocks, don't complain, cjwatson already cleaned a whole stack of those yesterday ;-)
[10:12] <dholbach> maybe we could add a new table for them at the bottom and not include them in the stats either
[10:12] <didrocks> seb128: yeah, I just continued on this :)
[10:13] <seb128> dholbach, I think they should be better on a list like nbs,e tc
[10:13] <dholbach> and add other tables like "sru nomination" there as well
[10:13] <seb128> they are really not sponsoring
[10:13] <seb128> they are archive? cleaning
[10:13] <cjwatson> yeah, they're moving around things that people with commit access already committed
[10:13] <cjwatson> practically by definition they aren't sponsoring
[10:14] <dholbach> ok, then I guess that should be a list on Harvest
[10:15] <dholbach> I'll file a bug about the package import thing then
[10:15] <seb128> dholbach, why harvest?
[10:15] <seb128> they are not really opportunities
[10:16] <seb128> they are things that need a review and be cleaned regularly
[10:16] <dholbach> where do you feel would be a prominent enough place for them?
[10:16] <seb128> we should have a list on a people page or a launchpad query url?
[10:17] <seb128> well, harvest would work as well I guess
[10:18] <dholbach> ok filed a bug about it
[10:18] <dholbach> bug 844659
[10:18] <seb128> dholbach, danke! ;-)
[10:18] <dholbach> (and added a comment to bug 833706)
[10:31] <pitti> can we use .tar.xz orig tarballs in Launchpad now?
[10:31] <pitti> upower only publishes xz tarballs these days
[10:31] <pitti> I saw cjwatson's announcement for data.tar.xz, but that's for binary packages
[10:32] <Laney> yes
[10:32] <cjwatson> pitti: xz source tarballs have worked for considerably longer
[10:32] <pitti> ok, thanks
[10:33] <cjwatson> ubiquity uses one
[10:33] <Daviey> barry: ISTR you were looking at a dupe of bug 827271, but can't find it right at the moment.  If you were, how is it looking?
[10:33] <pitti> they work for Debian now, too, so I can just upload/sync that one
[10:33] <pitti> cjwatson, Laney: thanks
[10:33] <cjwatson> landed on LP trunk 2011-03-26 (r12667)
[10:34] <Laney> colord was synced with .origi.tar.xz
[10:34] <Laney> yes, .origi!
[10:39] <gotwig> hey
[10:39] <gotwig> cjwatson: hey, could I ask you something about the "seed" system ?
[10:40] <cjwatson> sure
[10:40] <gotwig> cjwatson: PM ?
[10:42] <cjwatson> gotwig: is it private somehow?
[10:42] <gotwig> no :P
[10:42] <cjwatson> here is fine then
[10:42] <gotwig> cjwatson: so how does the "seed" system excactly work
[10:42] <gotwig> I dont understand it :/
[10:43] <gotwig> does it only use ubuntu, or debian and other distros, too ?
[10:44] <cjwatson> gotwig: seeds are just a set of top-level lists of package names, which are expanded based on their dependencies in a particular distribution
[10:44] <cjwatson> gotwig: it's certainly possible to expand seeds based on Debian or other distributions, but we only do so based on Ubuntu
[10:45] <gotwig> cjwatson: so why you dont simply use apt-get ?
[10:47] <cjwatson> gotwig: there are a number of contexts where we need to be able to predict what will happen without having an apt state conveniently available
[10:48] <cjwatson> gotwig: for actual installation we do in fact simply use apt-get (although typically, the task or metapackage it's installing is constructed based on seeds)
[10:48] <cjwatson> seeds are a build-time thing, not a run-time thing
[10:48] <gotwig> cjwatson: oh thanks for help :-)
[10:49] <gotwig> cjwatson: and can two packages have the same file?
[10:49] <cjwatson> gotwig: could you be more specific?
[10:49] <pitti> didrocks: I'm setting all your "WIP" package importer branches to "rejected"
[10:49] <pitti> really, pre-applied patches with .pc/ in bzr is utter utter madness
[10:49] <didrocks> pitti: oh, you have this power? lucky guy :)
[10:49] <pitti> developers can't get it right, the package importer can't get it right, bzr mu can't get it right
[10:50] <gotwig> cjwatson: as example, there is a configuration file in /etc/* , but I want to use an other configuration as specifified in that config file. Can I install an package, that "overwrites" the standard installed config file from the first package
[10:50] <pitti> it makes commits very hard to read, and is not what you generally expect when you have broken out patches in the first place
[10:50] <cjwatson> pitti: unapplying the patches out of sync with the importer is worse

[10:50] <pitti> (that's also one of the big reasons why we mostly don't use them in the desktop team)
[10:50] <Daviey> pitti: you don't enjoy reviewing .pc/* ? :)
[10:50] <cjwatson> gotwig: you have to use the Replaces field; whether it will do the right thing with any particular configuration file is a different matter
[10:51] <pitti> Daviey: I still don't know how to tear apart a chicken to commit the result of  adding a new patch so that the importer doesn't yell at me
[10:51] <pitti> Daviey: apparently you have to add some, but not all, of the new files in .pc
[10:51] <cjwatson> all but dotfiles
[10:51] <cjwatson> (I don't know why the importer doesn't import dotfiles)
[10:51] <gotwig> cjwatson: so when the first package upgrades, will it remove my configuration trought the 2.th package?
[10:52] <Daviey> I've just added them all.. but when in doubt or lazy, let the importer handle it. :/
[10:52] <pitti> that's what I tried in one of my more recent updates (not import dotfiles)
[10:52] <Daviey> not really cricket.
[10:52] <cjwatson> pitti: works for me
[10:52] <pitti> seems we didn't get a conflict there indeed
[10:52] <cjwatson> gotwig: it shouldn't if you've used Replaces, but I would strongly advise testing carefully
[10:52] <pitti> but still, this is so far apart from easy and intuitive..
[10:52] <gotwig> cjwatson: thanks again
[10:52] <Daviey> pitti: Have you tried UDD for SRU's?
[10:52] <pitti> Daviey: only for sponsoring
[10:53] <pitti> Daviey: I use the UDD branches for native packages
[10:53] <cjwatson> I wouldn't be wholly opposed to the importer changing to unapplied-patches, but it needs to be actually coordinated
[10:53] <pitti> Daviey: but in my very personal opinion they are broken by design right now for patched packages
[10:53] <cjwatson> although I strongly believe that applied-patches is the correct default for dpkg-source -x
[10:53] <Daviey> cjwatson: That would sensible, we can't start doing things that make sense.
[10:53] <pitti> we either need to keep broken-out debian/patches/* stuff, or use proper threads, without debian/patches/* stuff, but not both
[10:53] <cjwatson> that way users can see what code is actually being built, you know, radical suggestion
[10:54] <gotwig> :)
[10:54] <pitti> Daviey: and they don't work at all for packages where the packaging branch is a branch of upstream trunk in bzr
[10:54] <chrisccoulson> this is one reason why i don't use UDD branches for stuff i maintain
[10:54] <cjwatson> developers using bzr branches might be expected to know more about the source package format though
[10:54] <cjwatson> pitti: yes they do
[10:54] <Daviey> I hoped that bzr would become quilt .pc aware, and just suck it in and hide it from me.
[10:55] <cjwatson> pitti: I do it personally, not making it up :)
[10:55] <pitti> cjwatson: not for me
[10:55] <cjwatson> pitti: in fact they work *best* that way - you get unified bzr blame across packaging and upstream changes
[10:55] <pitti> cjwatson: as they have no relationship at all with trunk
[10:55] <cjwatson> which is the reason I like applied-patches
[10:55] <cjwatson> pitti: not the auto-imported branches, but a manually-imported branch with the right structure can be persuaded to play nicely
[10:55] <pitti> right, I mean the auto-imported ones
[10:56] <Daviey> cjwatson: Really, never - ever look at the eucalyptus branch.
[10:56] <pitti> for some packages with manual history we pushed them "over" the auto-import ones, and then things work of course
[10:56] <cjwatson> we aren't at a sufficiently late phase of the grand plan to have auto-imports based on upstream imports
[10:56] <cjwatson> although it is in the grand plan
[10:56] <Daviey> cjwatson: That was an experiment of importing from upstream bzr.. into our bzr
[10:56] <pitti> anyway, my venting aside, I cleaned your reviewed branches; thanks didrocks
[10:57] <cjwatson> that usually works fine as long as you're careful to have an intermediate branch representing release tarballs
[10:57] <cjwatson> which is, granted, fiddly
[10:57] <cjwatson> Daviey: the inability to push to lp:ubuntu/natty-proposed/package or whatever until an upload has been accepted and imported is the main problem for SRUs
[10:58] <Daviey> cjwatson: Before my time, it was experiemented of just re-merging from upstream which had an intermediate commit removing the upstream tarball.
[10:58] <Daviey> It didn't use patches, which meant it was essentially a fork
[10:58] <didrocks> pitti: thanks for setting to rejected. Will directly ping you next time rather than the "WIP workaround"
[10:58] <Daviey> measuring the delta was impossible.
[10:58] <cjwatson> ooh, I think I found the octave commit that unbreaks octave-symbolic
[10:58] <pitti> didrocks: fine for me
[10:59] <pitti> didrocks: we just can't reject them wholesale, sometimes there's an actual problem there
[10:59] <pitti> so they still need careful review
[10:59] <cjwatson> (SRUs> bug 668948)
[10:59] <didrocks> pitti: indeed, that's why I didn't unset the whole list
[10:59] <pitti> not sure why we get so many which are completely empty, though
[11:00] <cjwatson> pitti: in cases where the MP is empty, the trees are usually still slightly different - it's just that merging has no effect because one is a subset of the other
[11:00] <cjwatson> now and again I decide that it's worth merging richer history in such case
[11:00] <cjwatson> s
[11:00] <cjwatson> or re-merging, since the MP is for the original contents of the branch
[11:02]  * Daviey wonders how many people actually check to see if there staging commits in the UDD branch.
[11:02] <Daviey> (before uploading, not using UDD)
[11:38] <Snicksie> hi all, i'm trying to get involved in helping developing ubuntu, ive read https://wiki.ubuntu.com/ContributeToUbuntu and https://wiki.ubuntu.com/UbuntuDevelopment but i still find it difficult to know how I can help... anyone who can help me further with this?
[11:42] <Daviey> Snicksie: We like builds to be reproducible, we have an awful lot of packages that are failing to rebuild right now.  That would be a good area of contribution.
[11:43] <Snicksie> what do I need to help with that, Daviey ? :)
[11:43] <Daviey> Snicksie: Do you have a pbuilder or sbuild enviroment?
[11:44] <Snicksie> I installed all this stuff: sudo apt-get install --no-install-recommends bzr-builddeb ubuntu-dev-tools fakeroot build-essential gnupg pbuilder debhelper
[11:44] <Snicksie> it includes pbuilder :)
[11:46] <Daviey> Snicksie: pbuilder-dist oneiric i386 create <-- create env
[11:47] <Daviey> pull-lp-source qucs <-- grab the source package, of something reported to not build
[11:47] <Daviey> Snicksie: pbuilder-dist oneiric i386 build qucs*dsc <-- build it in a clean chroot, to check it's valid.
[11:47] <Snicksie> i've got an error, will paste the error
[11:47] <Daviey> Snicksie: bug 756183, is all yours.
[11:48] <Snicksie> http://pastebin.ws/aynmva
[11:49] <Daviey> Snicksie: Archive mirror you are using is poorly for oneiric.
[11:49] <Snicksie> how can I fix that? :p
[11:50] <Daviey> Snicksie: annoyingly, you are probably better off just waiting - but it's a good chance to do some reading :)
[11:51] <Snicksie> okay, have you got some suggestions about what to read? :)
[11:51] <Snicksie> wait, this time it works :p
[11:59] <Snicksie> Daviey, does it automatically create a build-log?
[12:01] <Daviey> Snicksie: yes, ~/pbuilder/oneiric-i386_result/last_operation.log iirc
[12:03] <Snicksie> okay :) So all I have to do now is waiting till it stops building? Should I do anything else, like assigning the bug to myself? What should I do after the build ended (successfull or not)?
[12:03] <Snicksie> okay, it failed already...
[12:04] <Daviey> Snicksie: I'm really sorry, but i can't give you my full attention at the moment.  You may also be able to get help in #ubuntu-motu ...
[12:04] <Snicksie> okay, will ask there :)
[12:05] <Daviey> Snicksie: doing http://pb.daviey.com/Cqow/, should give you a shell if the build fails... that you can poke it, and run "debian/rules binary" to experiment to find a fix
[12:06] <cjwatson> I generally only assign build failure bugs to myself once I've done a little initial investigation to determine that I have some hope of fixing it
[12:33] <Snicksie> Daviey, can I also use gedit (or another editor) to edit instead of only command-line?
[12:35] <Daviey> Snicksie: Hmm.. you can, not easily tho.
[12:39] <valavanisalex> Hi there, a new bug-fix-only version of Inkscape (0.48.2) is packaged in oneiric.  If I want to upgrade the natty (0.48.1) & maverick (0.48.0) packages, is it better to do this as an SRU or a backport?
[12:39] <cjwatson> backport
[12:40] <Laney> someone just requested a backport of that, was it you?
[12:40] <valavanisalex> Thanks... I thought backports had to include new features
[12:40] <Snicksie> Daviey, found out, I found the package in my home-directory and edited the file i wanted with gedit...
[12:40] <cjwatson> valavanisalex: it's more that SRUs normally must be targeted fixes only
[12:40] <valavanisalex> No I didn't request the backport, but I saw the request
[12:42] <valavanisalex> cjwatson: great - thanks for the clarification.  I'll start work on the backport checking then.
[12:44] <bdrung_> dholbach: done.
[12:44] <Daviey> Snicksie: Sorry, i thought you mean't within the pbuilder enviroment
[12:45] <bdrung_> dholbach: why is "Time in Queue" unknown, but correct in my local run: http://people.ubuntu.com/~bdrung/sponsoring/ ?
[12:45] <Laney> valavanisalex: there are some reverse dependencies ink-generator zoomer that you should check still work
[12:45] <valavanisalex> Laney: will do.  Thanks.
[12:47] <ahasenack> hi, can I get a sponsor for this SRU? https://bugs.launchpad.net/smart/+bug/244453
[12:48] <Snicksie> yeah, that was preferrable, but this >should< work too . unfortunately it doesnt really seem that any of my changes change... Is it because it uses the archives or because my change isn't really a change? :p
[12:49] <Snicksie> ah, it seems to be in the tmp
[12:51] <Daviey> ahasenack: didrocks, micahg and kenvandine are patch pilots today (or scheduled to be).. see if they can..
[12:52] <didrocks> Daviey: on unity releases, that's why I did my patch piloting really early :)
[12:52] <seb128> kenvandine is on holidays this week
[12:53] <ahasenack> so, micahg, whenever he comes in
[12:53] <ahasenack> almost 8:00 there, should be one our more or so
[12:54] <Daviey> ahasenack: I just subscribed ubuntu-sponsors, that increases the changes of it getting sponsored :)
[12:54] <Daviey> If nobody does it in the next few hours, i will have a look over it.
[12:54] <ahasenack> Daviey: uh, I thought I only needed to subscribe the sru team
[12:55] <ahasenack> who is ubuntu-sponsors?
[12:55] <Laney> the sru team review from the queue
[12:55] <ahasenack> a superset of the sru team?
[12:55] <Daviey> ahasenack: Normally it bakes in the unapproved queue, then the SRU team look at it, and accept or reject it based on the SRU report.
[12:55] <ahasenack> Daviey: so ubuntu-sponsors are the ones who upload to this queue
[12:56] <Daviey> ahasenack: People who want to do sponsoring,
[12:56] <Daviey> as in, some archive access.
[12:56] <ahasenack> Daviey: ok, thanks
[13:03] <dholbach> bdrung_, tumbleweed might know - I think it's something to do with permissions - AFAIR Stefano changed it to anonymous authentication
[13:03] <dholbach> bdrung_, thanks - I'll have a look at the branch in a bit
[13:04] <Laney> that was reverted
[13:05] <bdrung_> dholbach: we reverted the anonymous authentication
[13:05] <dholbach> bdrung_, ah great
[13:07] <dholbach> bdrung_, updated r122 → r125
[13:08] <dholbach> so that should fix the auth problem too
[13:40] <pitti> sabdfl: looks like there's not much on topic for today's TB meeting?
[14:03] <jml> kirkland: how could I tell if I was running powernap?
[14:04] <kirkland> jml: sudo status powernap
[14:04] <jml> kirkland: unknown job. I guess that means "no".
[14:04] <kirkland> jml: that's a "no", then
[14:08] <sabdfl> hey pitti
[14:23] <smoser> SpamapS, slangasek bug 839595 has some interesting/expected comments from a user.
[14:43] <bdrung> Laney: do we need a FFe for u-d-t 0.129?
[14:44] <Laney> yes, but I'll approve it
[14:48] <bdrung> Laney: bug #844869
[14:50] <Laney> bdrung: done, I added an lptools task for you
[14:52] <bdrung> Laney, tumbleweed: do you know if LP closes bugs automatically if you close them in the changelog and use the new sync API?
[14:53] <Laney> bdrung: https://bugs.launchpad.net/launchpad/+bug/833736 went to Fix Released, so I guess it is supposed to
[14:53] <doko> Sweetshark, ooo-build-extensions ping
[14:53] <tumbleweed> bdrung: it's no supposed to, yes
[14:53] <tumbleweed> now
[14:54] <tumbleweed> haven't tested it
[14:54] <Laney> we'll see if it works
[14:54] <Laney> give it a go
[14:54] <bdrung> ok, let's see if it works. :)
[14:54] <Sweetshark> doko: im in conf call
[14:54] <Sweetshark> later
[14:56] <tumbleweed> dholbach: did I understand correctly from the backscroll, that you bzr updated ubuntu-sponsoring, and it's sane again?
[14:57] <dholbach> tumbleweed, with a bit of confusion it should, yes
[14:57] <tumbleweed> cool
[14:57] <tumbleweed> you are wanting to move the out of date UDD branches into a separate table? will that not lead to them being neglected?
[14:58] <tumbleweed> that code must really be broken into seperate download and render jobs, for ease of development...
[15:00] <Laney> auto closing seemed to work
[15:00] <Laney> nice
[15:00] <tumbleweed> \o/
[15:01] <bdrung> Laney: really?
[15:01] <bdrung> haven't received a mail
[15:03] <bdrung> great, it works.
[15:22] <brendand> does old-releases.ubuntu.com have an rsync server?
[15:22] <micahg> ahasenack: sorry, not piloting today, I might be able to sponsor something late tonight
[15:23] <soren> brendand: Why don't you just try?
[15:23] <ahasenack> micahg: so no pilots today? ok
[15:23] <soren> brendand: "rsync old-releases.ubuntu.com::" isn't that hard.
[15:23] <ahasenack> micahg: I think zul was going to sponsor it
[15:24] <zul> ahasenack: is this the smart stuff?
[15:24] <ahasenack> zul: yes
[15:24] <zul> ahasenack: already taken care of
[15:24] <ahasenack> zul: ah,cool, thanks
[15:24] <micahg> ahasenack: didrocks piloted earlier, sorry, still cleaning up after DigiNotar
[15:25] <ScottK> didrocks: If I read Bug #823061 correctly, that change got uploaded before the FFe review was done.  Is that correct?
[15:27] <didrocks> ScottK: no, the release is just happening now
[15:27] <didrocks> ScottK: it has been merged *upstream* before the FFe review was done
[15:27] <didrocks> ScottK: I warned dx about it
[15:27] <didrocks> ScottK: and now it's sorted out
[15:27] <ScottK> didrocks: OK.  It seems someone got the bug tasks a bit mixed then.
[15:28] <ScottK> That or I read it wrong.
[15:28] <ScottK> Thanks.
[15:28] <didrocks> ScottK: yeah, the unity-2d task shouldn't be fix released, Kaleo push it by error
[15:29] <Kaleo> didrocks, ScottK: sorry about that :)
[15:29] <ScottK> Kaleo: No problem.  Things happen.
[15:29] <didrocks> ScottK: so right now, the doc team acked the freeze and in a few hour, we will get unity and unity-2d upload fixing this ui bug
[15:30] <ScottK> didrocks: I think you should answer pitti's concern too.
[15:30] <didrocks> ScottK: that was discussed between jbicha, pitti and njpatel on #ubuntu-desktop
[15:30] <ScottK> Ah.  OK.
[15:30] <ScottK> Great then.
[15:30] <ScottK> Please note that in the bug then.
[15:31] <didrocks> sure, doing
[15:31] <doko> barry, fyi, flufl packages still ftbfs in oneiric
[15:31] <Sweetshark> doko: wrt bug 755987, never knew much about that package, but it is still available in debian sid and the breaker seems to be just a update of the dep from openoffice.org-dev to libreoffice-dev ...
[15:32]  * Sweetshark tries a small and simple fix.
[15:32] <doko> Sweetshark, thanks!
[15:36] <barry> doko: dang
[15:37] <doko> barry, ahh, wait, that was lazr.* ...
[15:37] <doko> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110816-oneiric.html
[15:37] <barry> :)
[15:38] <barry> doko: i'll look at those
[15:40] <doko> barry: other two popular maybe are python-event (needs porting to libevent2, and in NBS), and maybe python-lucene, but scan the page yourself ...
[15:40] <barry> doko: yep, i've been looking at python-related packages off that page
[15:42] <bdrung> tumbleweed: what's your idea how to fix bug #823832?
[15:45] <SpamapS> smoser: you answered his questions the same way I would have. :)
[15:46] <tumbleweed> bdrung: this isn't the only thing that requires people doing ubuntu-dev on debian systems to add an /etc/dpkg/origins/ubuntu (for example, you need to do that to generate Launchpad-bugs-fixed)
[15:48] <bdrung> tumbleweed: but then backporting from debian to ubuntu is still broken
[15:48] <tumbleweed> yes
[15:50] <Laney> let the user specify a vendor in -s/-d?
[15:50] <Laney> -s ubuntu/maverick ...
[16:01] <bdrung> tumbleweed: what do you think about using the vendor chain and then hardcode ["ubuntu", "debian"] after that?
[16:02] <bdrung> Laney: ^
[16:03] <Laney> I don't know what the vendor chain is
[16:03] <bdrung> Laney: ubuntutools/misc.py -> system_distribution_chain
[16:03] <bdrung> says: Detect the system's distribution as well as all of its parent
[16:03] <bdrung>     distributions and return them as a list of strings, with the
[16:03] <bdrung>     system distribution first (and the greatest grandparent last). If
[16:03] <bdrung>     the distribution chain can't be determined, print an error message
[16:03] <bdrung>     and return an empty list.
[16:04] <bdrung> this will be ["debian"] on debian and ["ubuntu", "debian"] on ubuntu
[16:09] <bdrung> tumbleweed, Laney: proposed fix: system_distribution_chain
[16:09] <bdrung> http://paste.ubuntu.com/685382/
[16:10] <tumbleweed> bdrung: seems plausible
[16:11] <tumbleweed> I think we need a documentation file / wikipage for doing ubuntu-dev on debian
[16:11] <Laney> hmm
[16:12] <Laney> why not just make it search all known distros?
[16:13] <Laney> seems weird to special case like that
[16:15] <tumbleweed> Laney: it's ubuntu-dev-tools, the only distro it absolutely has to search is Ubuntu (and debian is the parent, so it should be searched after ubuntu)
[16:16] <tumbleweed> but yeah, it's overly generic when there are only 2 distros that matter here :)
[16:17] <broder> blame persia for that - he gave me crap when i proposed a non-generic solution :-P
[16:19] <Laney> I just mean to make codename_to_distribution independent of the current distribution
[16:19] <broder> the goal was to leave room to make backportpackage useful for ubuntu derivatives
[16:19] <broder> i don't really know if i succeeded or not
[16:20] <bdrung> broder: btw, mint uses ubuntu as deb_vendor
[16:22] <pitti> didrocks, ScottK: yeah, my concern is that these features should be FFEed first and then have work effort assigned to it
[16:22] <pitti> otherwise it's rather pointless
[16:25] <ScottK> Agreed.
[16:27] <Sweetshark> arrgh
[16:27] <Sweetshark> anyone around who can help me out with how udd is supposed to work?
[16:30] <ScottK> barry knows everything about UDD.
[16:30] <Laney> Is the hot new syncpackage going to be announced now that it's in? :-)
[16:31] <tumbleweed> bdrung: does mint rebuild?
[16:32] <ScottK> Laney: Is there some agreement on how and when it should be used?
[16:32] <Laney> it's not suitable for sponsoring yet (due to attribution), but otherwise for requested syncs
[16:32] <Laney> AFAIK anyway
[16:33] <ScottK> Probably someone like cjwatson should write a mail to u-d-a if he thinks it's ready for general use.
[16:34] <pitti> Laney: is that in ubuntu-dev-scripts? I thought that syncpackage script was just an improvement of my original hack which just crafts an appropriate .changes file for a .dsc?
[16:34] <Laney> pitti: Yeah. It was that, but now it uses the LP API to do it properly.
[16:34] <pitti> nice!
[16:34]  * pitti dist-upgrades
[16:34] <bdrung> tumbleweed: probably no (just add packages)
[16:34] <Laney> give LP much kudos for that
[16:35] <bdrung> Laney: there is still the bug that the syncer isn't credited
[16:36] <Laney> that's got a branch being reviewed now.
[16:37] <ScottK> " ... feel free to use it now if you aren't vain enough to care about who gets credit for the upload in Launchpad."
[16:38] <Sweetshark> I did 1) bzr branch ubuntu:ooo-build-extensions 2) modify debian/control 3) modify source 4) dch "move dependencies to libreoffice (LP: #755987)" 5) dch "move build paths to libreoffice"
[16:40] <Sweetshark> how do I continue? 6) bzr commit && bzr push lp:~bjoern-michaelsen/ubuntu/oneiric/ooo-build-extensions-lp755987 ?
[16:43] <Laney> ScottK: it means you don't get emailed about build failures though
[16:43] <ScottK> True, but I tend to not rely on email for that anyway.
[16:44] <Laney> Experience tells me some people do ;-)
[16:45] <ScottK> No doubt.
[16:45] <ScottK> Plenty seem to not manage to notice even with the email.
[16:48] <Sweetshark> pitti: would you sponsor a fix for bug 776594? if so, how should I publish the fix?
[16:48] <Sweetshark> pitti: ups
[16:48] <Sweetshark> pitti: wrong bug hang on
[16:48] <Sweetshark> pitti: bug 755987
[16:50] <Sweetshark> pitti: https://code.launchpad.net/~bjoern-michaelsen/+junk/ooo-build-extensions-lp755987 does this mix of dpatch and udd work?
[17:49] <mdz> sabdfl, you're chairing tech board today?
[17:50] <pitti> hey Sweetshark
[17:52] <pitti> Sweetshark: just r10? or more?
[17:55] <pitti> Sweetshark: UDD and dpatch are completely different things, so that should be ok
[17:59] <bdmurray> pitti: https://code.launchpad.net/~brian-murray/apport/add-apport-version/+merge/74659
[18:03] <pitti> Sweetshark: posted on the bug; needs dpatchification indeed
[18:08] <pitti> bdmurray: ah, thanks! merging
[18:09] <bdmurray> pitti: no problem, thank you.  This should help some confusion I sometimes have. ;-)
[18:35] <bdrung> tumbleweed: time for another upload?
[18:35] <bdrung> of u-d-t
[18:36] <bdrung> tumbleweed: care about fixing bug #844992?
[18:38] <bdrung> tumbleweed: and bug #791956?
[18:50] <doko> jamespage, still online? could you have a look at libspring-2.5-java? currently ftbfs, the ubuntu changeset can be dropped, but I didn't check for updated dependencies
[19:26] <jamespage> doko: ack - can't do now but will first thing tommorow
[19:27] <doko> jamespage, thanks, but no haste, just for oneiric
[19:47] <doko> Daviey, just gave back fbasics and fgarch in the test archive. still ftbfs. could you reopen the reports?
[19:53] <bdrung> ScottK: you did the change in requestsync that causes bug #844992. will you update the man page?
[19:54] <ScottK> bdrung: I can't promise when I'll get to it.
[19:55] <ScottK> I don't generally hack on u-d-t, it was more of a it suddenly broke, so it needed to get fixed ASAP kind of thing.
[19:55] <bdmurray> @pilotin
[19:55] <udevbot> Error: "pilotin" is not a valid command.
[19:55] <bdmurray> @pilot-in
[19:55] <udevbot> Error: "pilot-in" is not a valid command.
[19:56] <bdmurray> @pilot in
[19:59] <bdmurray> How or who can set https://code.launchpad.net/~jtaylor/ubuntu/natty/pyfltk/fix-779340/+merge/68194 to merged?
[20:01] <bdmurray> cjwatson: How or who can set https://code.launchpad.net/~jtaylor/ubuntu/natty/pyfltk/fix-779340/+merge/68194 to merged?
[20:11] <hallyn> bzr branch lp:ubuntu/natty/libvirt libvirt-n
[20:11] <hallyn> bzr: ERROR: Revision {james.westby@ubuntu.com-20110318080232-bskde7dqc2icfixv} not present in "Graph(StackedParentsProvider(<bzrlib.repository._LazyListJoin object at 0x2eb6ed0>))".
[20:12] <micahg> hallyn: as an aside, you most probably want natty-proposed or natty-security
[20:13] <hallyn> micahg: well that's one i've asked about before:  natty-proposed does not exist in bzr
[20:13] <hallyn> i'm not allowed to create it
[20:13] <micahg> hallyn: right, UDD needs to create it, it should be done automatically once an upload happens
[20:14] <micahg> which already has happen which means it's an importer failure
[20:14] <hallyn> so is there a way to force it?
[20:14] <hallyn> to help UDD along?
[20:15] <micahg> file a bug against the UDD project for the import failure if one doesn't exist
[20:17] <hallyn> That exists
[20:21] <hallyn> micahg: but so noone is ablt to do a 'bzr push' to force it to happen? :)
[20:21] <micahg> hallyn: not that I know of
[20:21] <hallyn> micahg: thanks
[20:21] <micahg> hallyn: maybe ask poolie nicely to have someone fix the import failure
[20:29] <ScottK> doko: Can you take a look at the kdesdk FTBFS on powerpc?  We've got no developer in the Kubuntu team with powerpc hardware, so we need some help.
[20:29] <hallyn> poolie: pretty please?
[20:32] <doko> ScottK, sorry, not for oneiric. however everybody within Canonical could do this
[20:32] <ScottK> doko: There's no Canonical representation among Kubuntu developers this cycle.
[20:33] <sbeattie> So how am I supposed to unwind a quilt patch where a merge from debian modified one of the files in the patch, such that the original file in .pc/patch/ is now different from what the file would look like with the quilt patch popped off, causing quilt to complain that the patch does not remove cleanly.
[20:33] <doko> ScottK, Riddell didn't loose his permissions while on rotation ;) and I'm not Kubuntu for sure
[20:33] <ScottK> Well, no he didn't, what he lost was time.  I'll see if I can find someone.
[20:34] <doko> sorry, lacking time myself
[20:34] <micahg> sbeattie: quilt pop before merging
[20:34] <ScottK> Ohh.
[20:35] <ScottK> micahg: Any chance you could help out with my powerpc FTBFS? ^^^
[20:35] <micahg> ScottK: hah, figured you would ask me, definitely not this week, if things slow down next week, I can try
[20:35] <ScottK> OK.  Thanks.
[20:36] <sbeattie> micahg: blah, okay.
[20:36] <doko> heh, he did volunteer to fix armel NBS first :-P
[20:36] <micahg> ScottK: just poke me if you don't hear from me by mid-next week
[20:36] <ScottK> OK.
[20:36] <micahg> doko: this is true...
[20:37] <sbeattie> micahg: oh, bleah, the patch in question still doesn't unapply cleanly.
[20:38] <micahg> sbeattie: sorry, did you pop -a to get them all?
[20:39] <sbeattie> micahg: I'm trying to do the initial pop before merging, for this package (openssl) the last (first to be popped off) in the series fails to pop off.
[20:40] <micahg> orly? maybe the importer failed on it?
[20:40] <micahg> nope, weird...
[20:45] <barry> ScottK: hey, if you want to spot me $200 to fix the power supply on my ol' dual-g5, i'd be willing to look into it <wink>
[20:46] <barry> sbeattie: still having trouble with quilt?
[20:49] <sbeattie> barry: yes, still trying to unwind a .pc that's out of sync without losing changes. I think force-popping and the updating the patch to apply will fix it, but I'm fearing that I'll end up reverting a change that I shouldn't.
[20:50] <barry> sbeattie: is this a udd branch (i.e. bzr branch ubuntu:foo ?)
[20:50] <sbeattie> barry: yes
[20:51] <barry> sbeattie: okay, first, i sympathize ;)   second, i do this all the time.  just finished one with python-virtualenv, so i will try to help ya!
[20:51] <barry> sbeattie: when you first get the branch, all the patches are applied
[20:52] <barry> sbeattie: so, e.g. when i wanted to merge-upstream, i first did `quilt pop -a` to get a pristine source branch
[20:52] <barry> sbeattie: then i did the bzr merge-upstream and committed those changes
[20:52] <sbeattie> barry: as an aside, that should get added to http://developer.ubuntu.com/packaging/html/udd-merging.html
[20:52] <barry> sbeattie: then i had to verify/update all the patches.  indeed they all failed to apply cleanly, so one-by-one i did the following:
[20:52] <barry> sbeattie: best to file a bug on ubuntu-packaging-guide for that
[20:53] <barry> sbeattie: okay, so what *i* do (which i am not claiming is the best way to do it, but iwfm)
[20:53] <barry> quilt push -f
[20:53] <sbeattie> barry: in this case, I reverted all changes to my merge (bzr revert); however, the last patch in the series after the revert still fails on quilt pop
[20:53] <barry> then apply any .rejs manually, fix any other patch problems, etc.  then `quilt refresh`
[20:54] <barry> rinse & repeat
[20:54] <sbeattie> (the last patch in the series is an ubuntu applied patch not in debian)
[20:54] <barry> sbeattie: so right after you grab the branch, you can't pop -a ?
[20:54] <barry> sbeattie: what's the branch url?
[20:54] <sbeattie> barry: lp:ubuntu/openssl
[20:55] <barry> sbeattie: let me try it...
[20:55] <barry> sbeattie: okay, i did this:
[20:56] <barry> bzr branch ubuntu:openssl oneiric
[20:56] <barry> cd oneiric
[20:56] <barry> quilt pop -a
[20:56] <barry> and that succeeded
[20:56] <barry> sbeattie: can you try again with a clean branch?
[20:56] <sbeattie> barry: how odd; bzr st tells me I have no changes (and I did no commits) and it fails.
[20:57] <sbeattie> barry: yeah, will do.
[20:57] <barry> sbeattie: those .pc directories kill you every time
[20:57] <barry> sbeattie: yeah
[20:57] <sbeattie> as a quilt user for 6+ years, checking them in feels very, very wrong to me.
[20:58] <barry> sbeattie: yeah, it's a design goal of udd to want the source branch to have all patches applied, but it gets very very tricky
[20:59] <barry> i usually end up doing all my work in a separate branch, then do a final merge back into ubuntu:foo and revert any .pc directory changes before i commit and push
[20:59] <barry> i can pretty much get reasonable results now, but it's a known problem that the udd/bzr guys are working on
[21:07] <tumbleweed> bdrung: err, no I think the pull-lp-source patch was nice (if hacky), but nothing else was that urgent. I'd like to see if we hit some big syncpackage issues. Also the change in lp of having debian versions Published rather than Pending may affect some things
[21:08] <bdrung> tumbleweed: release early, release often
[21:08] <sbeattie> barry: quilt pop still fails for me after a clean checkout; wondering if it's anything specific to my quilt settings; do you have QUILT_PATCHES set to debian/patches?
[21:08] <tumbleweed> sure, but I don't see the urgency
[21:09] <barry> sbeattie: yep
[21:09] <bdrung> tumbleweed: but i didn't saw something blocking :)
[21:09] <barry> sbeattie: how odd
[21:10] <barry> sbeattie: i also have: QUILT_REFRESH_ARGS=-p ab --no-timestamps --no-index
[21:10] <barry>  
[21:12]  * sbeattie reads through quilt --trace output to look for what's going wrong.
[21:12] <tumbleweed> bdrung: oh, I see you've already tagged it :)
[21:13] <bdrung> tumbleweed: already uploaded (some hours ago)
[21:13]  * tumbleweed was out
[21:24] <sbeattie> barry: weeeeird. I had QUILT_PATCH_OPTS="--unified-reject" set in my .quiltrc, unsetting that caused quilt pop -a to work.
[21:26] <sbeattie> barry: which looks to be a no-longer valid argument to patch. µ.
[21:27] <barry> sbeattie: yeah, i was just going to say i couldn't find that in the manpage ;)
[21:28] <nigelb> sbeattie: I admire your patience. About this time I'd be headdesking or breaking the keyboard into two ;)
[21:29] <barry> nigelb: i already did that three times today, but it was because i tried to use git :)
[21:29] <bdmurray> barry: you are on your 4th keyboard?
[21:29]  * sbeattie looks at the four smashed keyboards over in the corner and thinks "what nigelb doesn't know won't hurt him."
[21:30] <nigelb> barry: Ouch. I didn't know git was that bad.
[21:30] <nigelb> sbeattie: heh :)
[21:30] <barry> bdmurray: i keep spares around just for the occasional forehead tickling
[21:30] <bdmurray> barry: what needs to happen to https://code.launchpad.net/~jtaylor/ubuntu/natty/pyfltk/fix-779340/+merge/68194 to get out of the sponsorship queue?
[21:31] <barry> bdmurray: hmm, good question.  looks like mdeslaur approved the change and was going to do an sru.  do you know if that happened?  (not that i can really help with that 'cause i can't do sru approvals afaict)
[21:32] <bdmurray> barry: its all fix released it just that the status of the mp is needs review
[21:33] <barry> bdmurray: oh.  i think only ~ubuntu-branches can change the status.  i'm not on that team either and have no pencil button next to the status.
[21:33] <bdmurray> barry: so hunt somebody down in that team then?
[21:33] <barry> bdmurray: i believe so
[21:35] <sbeattie> barry: re git: if it make you feel any better, I'm also cherrypicking patches from openssl upstream… which uses cvs. I'd forgotten how hard it was to pull out individual untagged commits from cvs.
[21:35] <barry> sbeattie: let's bring back rcs and sccs!
[21:35] <bdmurray> bdrung: what I mean in bug 807644 is that code names should only be used for the development release after they are released they should be the number
[21:36] <bdrung> bdmurray: for which use case?
[21:36] <bdrung> bdmurray: for the end user?
[21:37] <bdmurray> bdrung: if I use distro-info --all I see a bunch of code names
[21:38] <bdrung> bdmurray: and you want to see a mix with code names and numbers?
[21:39] <bdrung> or just numbers?
[21:39] <bdmurray> bdrung: I think just numbers unless its the devel release
[21:39] <broder> bdmurray: i think that significantly hampers distro-info's usefulness as a dev tool
[21:40] <bdrung> bdmurray: that's not useful for scripts using distro-info
[21:42] <bdmurray> bdrung: okay I guess the package description makes it clear that "distro-info script will give you the codename" but the man-page and --help don't
[21:42] <bdmurray> bdrung: I mean that seems reasonable but my confusion, if you will, is understandable - to me at least ;-)
[21:46] <bdrung> bdmurray: do you want a switch to show the version numbers? like http://paste.debian.net/128918/
[21:48] <bdmurray> bdrung: yes, its beats checking wiki.ubuntu.com or trying to remember
[21:48] <bdrung> bdmurray: can you update the bug report?
[21:49] <bdrung> bdmurray: i even could show the full name like 10.04 LTS "Lucid Lynx"
[21:49] <bdmurray> I think that'd be ideal
[21:50] <bdrung> and 5.0 "Lenny" for debian
[21:55] <infinity> bdrung: Maybe a "full name" option or something?
[21:55] <infinity> bdrung: Or, basically, the same output options you get from lsb_release.
[21:56] <bdrung> infinity: lsb_release doesn't know the full code name
[21:56] <infinity> bdrung: I can see wanting several different types of output, but if I want to loop through codenames, the current output is useful, and passing it through cut or something would be annoying.
[21:56] <infinity> bdrung: Sure it does.
[21:57] <infinity> bdrung: Err, it knows the archive-level codename.
[21:57] <infinity> bdrung: That lowercase codename is the useful one. :P
[21:57] <bdrung> infinity: which different types of output do you want?
[21:57] <infinity> bdrung: Well, I'm happy with the current output.
[21:58] <infinity> bdrung: bdmurray seems to want numbers, and I can see why that's also handy.
[21:58] <infinity> bdrung: And an output that maps A to B would be keen too, I'm sure.
[21:58] <bdrung> infinity: the full name would be for humans and there i would prefer the longest one
[21:58] <infinity> bdrung: Yeah, the full names would be neat.
[21:59] <infinity> bdrung: So, -c (codename), -r (release version), and -f (full name)?
[21:59] <infinity> bdrung: And default to -c, to not break backward compat with people already using it.
[22:00] <bdrung> infinity: sounds plausible. can you comment the bug with that?
[22:00] <bdrung> bdmurray, infinity: would having "Ubuntu" in the beginning useful for the full name mode?
[22:01] <bdrung> -> Ubuntu 10.04 LTS "Lucid Lynx"
[22:01] <bdrung> -> Debian 5.0 "Lenny"
[22:02] <bdmurray> If I used --supported I'd see Ubuntu 4 or 5 times which seems excessive ...
[22:02] <infinity> Not sure you need the quotes there.  I'm not picky about Debian/Ubuntu being in the string (though, for trademark reasons, it perhaps should be).
[22:02] <infinity> Since it's not just "10.04", it's "Ubuntu 10.04".
[22:02] <infinity> LTS, even, in that case.
[22:02] <infinity> But yeah.
[22:02] <infinity> For the "-f" case, it should probably be the real full name.
[22:03] <bdmurray> and what about 10.04.3?
[22:03] <bdrung> bdmurray: i haven't collected data about that case
[22:03] <bdmurray> I don't think it shows up in Launchpad anyway
[22:04] <infinity> The only place point releases show up is base-files, really.
[22:04] <bdrung> infinity: for the -f case, you want "Ubuntu" in the name?
[22:04] <infinity> And ISO images, if/when we update them.
[22:05] <infinity> bdrung: I would consider that more "correct", yeah.
[22:05] <bdrung> ok.
[22:05] <bdrung> and following will the correct (with the quotes): Ubuntu 10.04 LTS "Lucid Lynx"
[22:05] <bdrung> ?
[22:05] <infinity> I realise it'll look silly when you list --all with "Ubuntu" 12 times, but whatever.
[22:06] <bdrung> infinity: it's your decision. i have one -1 from bdmurray and i am not decided yet
[22:07] <bdmurray> I take it back
[22:08] <infinity> bdrung: I'm for correctness over worrying about "icky" output.  The product is "Debian 5.0" or "Ubuntu 7.04", not "5.0"
[22:08] <infinity> bdrung: (And people can get just the version list with the proposed "-r")
[22:09] <bdrung> infinity, bdmurray: compare http://paste.ubuntu.com/685623/ with http://paste.ubuntu.com/685624/
[22:10] <bdrung> tumbleweed: your opinion about ^?
[22:10] <bdmurray> I like http://paste.ubuntu.com/685623/ better
[22:10] <infinity> Definitely with the product name.
[22:11] <infinity> SO, 623.
[22:11] <bdrung> ok, then it's decided
[22:12] <infinity> (Also, thanks for bringing this up in -devel and making me aware of the tool) :P
[22:12] <infinity> Very handy.
[22:15] <bdrung> infinity: mailing list or IRC?
[22:15] <infinity> bdrung: As in, just now.
[22:16] <infinity> Always happy to discover a useful little tool.
[22:16] <bdrung> :)
[22:16] <bdrung> infinity: do you know wrap-and-sort and suspicious-source?
[22:16] <bdrung> and sponsor-patch?
[22:16] <infinity> Nope!
[22:16] <bdrung> then it's time
[22:16] <infinity> I can only learn one new thing per day.
[22:44] <ambro718> Hi. How do I get an upstart embedded script to be executed by bash not dash?
[22:46] <poolie> hi micahg, hallyn, what's the bug number/s?
[22:47] <broder> ambro718: you can recompile upstart to do that, or you could put the script in a separate file and have the upstart config call that
[22:47] <broder> ambro718: but you should probably try to rewrite the script without bashisms
[22:47] <broder> because bash is much slower than dash, especially since it won't already be loaded into memory
[22:48] <ambro718> broder: I have a /etc/default/something which has an array of command line arguments, like MY_ARGS=( "First Argument", "  Second Argument  " ). How do I rewrite that?
[22:49] <ambro718> broder: I just do: exec <hardcoded args> "${MY_ARGS[@]}"
[22:49] <ambro718> not so much in dash which upstart calls.
[23:01] <broder> jono: we don't really know how much of the "number of times to get approved" was affected by quorum issues, do we?
[23:04] <Laney> What is implied by the number of times to get approved statistics?
[23:05] <Laney> I'm most concerned that nobody cares about backports :P
[23:06] <infinity> ambro718: Why do you need your args in an array rather than just a string?
[23:06] <ajmitch> Laney: of course we care
[23:07]  * Laney cares about bed currently
[23:07] <Laney> nighty night
[23:07] <broder> Laney: i think it's self-feeding. backports don't get approved so people don't bother with backports. there's not enough interest around backports so people don't approve them
[23:08] <broder> honestly, i hate it when people do this, but i find myself tempted by something awful like WONTFIXing all open backport requests, starting over and trying to keep a better handle on things
[23:08] <Laney> nah, just keep on top of new ones and the old requests will take care of themselves by releases going EOL
[23:09] <ambro718> infinity: ... because individual arguments may contain spaces ...
[23:10] <ambro718> infinity: and not just theoretically, but actually
[23:10] <infinity> ARGS='-p arg -f "arg 2" -q "arg 3 whee"'?
[23:10] <ajmitch> broder: you could do it by 'accident'
[23:11] <ajmitch> 165 open on lucid-backports, that's quite a few
[23:11] <broder> though when i think about this more, i remember that hte problem is we need better tools than we have
[23:11] <Laney> some of our requirements are really annoying, like test /all/ rdeps and test on /all/ intervening releases
[23:11] <ambro718> infinity: doesn't work probably
[23:11] <infinity> ambro718: These are command-line args?
[23:11] <infinity> ambro718: If so, how do you call it on the CLI?
[23:11] <ajmitch> sometimes I just care about having something work on lucid, since it's LTS
[23:12] <broder> ajmitch: yes, but the backports requirements are that it work on everything between lucid and oneiric
[23:12] <ambro718> infinity: my_program "first argument" "second argument"  (just one way to do it)
[23:12] <Laney> it's too much to ask requesters really
[23:12] <ajmitch> testing on maverick & natty as well is a bit much for some packages
[23:12] <Laney> so stuff doesn't get done
[23:12]  * ajmitch spots python-django in the list
[23:12] <infinity> ambro718: Right, then this works: ARGS='"first arg" "second arg"'; my_program $ARGS
[23:13] <broder> Laney: i agree with you, but i also agree with the principle behind the requirement
[23:14]  * Laney shrugs
[23:14] <Daviey> doko: Odd!  They are building for me :/
[23:14] <broder> maybe if we could use stgraber's app preview thing we could make it easier
[23:15] <ajmitch> broder: so what should be done with all those open requests?
[23:15] <infinity> ambro718: Or not.  Hrm.
[23:15] <infinity> ambro718: I know there's a way to make this work. :P
[23:16] <broder> ajmitch: figure out the patterns, then teach a tool to do the same
[23:16] <ambro718> infinity: is not... which is why all shell scripts should be destroyed....
[23:16] <broder> ajmitch: honestly, 85% of the backports testing process could be overseen by a bot instead of a human
[23:16] <broder> and that would be the *real* answer
[23:17] <ajmitch> how much testing are requestors required to do for a package?
[23:17] <Daviey> doko: Ah, did you give back to natty?
[23:17] <ajmitch> checking that the package installs is easy enough, checking that some functionality still works is a bit harder to automate
[23:17] <doko> Daviey, if you think they do work, please upload these as *buildN* versions to oneiric
[23:17] <doko> Daviey, no oneiric
[23:18] <cjwatson> bdmurray: I've marked that pyfltk branch as merged now
[23:18] <doko> Daviey, your haskell geive-back did succeed, thanks!
[23:18] <broder> ajmitch: our requirements for "runs" are pretty minimal. you could probably do something like..
[23:19] <broder> ajmitch: run every binary in an X environment. sleep for 5 seconds, then capture console output and a screenshot. show the output/screenshots to a backporter and let them decide whether that counts as "running"
[23:19] <broder> then over time you build up blacklists ("Segmentation fault" does not count as "running", etc...)
[23:19] <Daviey> doko: excuse the utf-8 fail.. but http://pb.daviey.com/Rn8O/
[23:21] <doko> Daviey, what I did learn is to do the rebuild test under the umbrella of a team, so that more people than me can do give-backs
[23:22] <ajmitch> broder: I imagine that wouldn't be particularly hard to automate with testing in a VM
[23:22] <Daviey> doko: sounds wise
[23:24] <doko> Daviey, acknowleged, and you're under arrest for the next one ;-P
[23:25] <bdmurray> cjwatson: thanks
[23:26] <ajmitch> broder: I'll try & do a quick & dirty PoC in virtualbox this weekend if you want :)
[23:26] <broder> ajmitch: i never say no when other people offer to write code for me :)
[23:27] <ajmitch> though on my hardware, 5 seconds would be very optimistic
[23:27] <broder> ajmitch: the number can be whatever you want. especially if it's autonomous, performance really just isn't a concern
[23:30] <ajmitch> broder: I'll see what I can do, I've already got VM images of most releases which I can snapshot & automate
[23:31] <broder> ajmitch: awesome, i'm looking forward to it
[23:36] <ajmitch> broder: yeah, it's not too dissimilar to some of the testing stuff I've been doing at work lately, so I already have a bit of it working :)
[23:44] <stgraber> broder: I actually have some code that you may find interesting for backports
[23:44] <stgraber> broder: it's code that I've been working on as a proof of concept for ARB and commercial apps
[23:45] <broder> stgraber: go on... :)
[23:45] <stgraber> broder: basically a debhelper script that moves all your package to /opt/extras.ubuntu.com/<package name> except your .desktop that are simply modified to use arb-wrapper
[23:45] <stgraber> broder: arb-wrapper uses fuse to create an overlay of your filesystem and the content of /opt/extras.ubuntu.com/<package name>
[23:45] <stgraber> broder: and then uses fakechroot to run the software
[23:46] <ajmitch> stgraber: that reminds me, I'll mail that list of bugs to the arb list
[23:46] <stgraber> broder: so the application will stil lthink it's running on a regular system, but it won't be affecting other software running on your machine
[23:46] <broder> stgraber: hmm..could be useful, although i think the biggest barrier to backports testing right now is our requirements about testing across multiple releases
[23:46] <broder> but we might be able to solve that with chroots
[23:48] <stgraber> broder: yeah, for that specific case I don't have code yet but saw some code around a while ago to basically get a list of everything a given binary is going to use on the system
[23:48] <stgraber> broder: you could then bundle all of that and run it in a chroot using file system overlay, not having to care about what's on the system
[23:48] <stgraber> though you're going to waste a lot of space doing it
[23:49] <broder> that's not really as much of a concern for us. everything in backports started in the main archive, so there's a pre-assumption of trustworthiness
[23:49] <stgraber> so probably only worth doing in some very specific corner cases (very old binary app that needs to run on a recent machine comes to mind)
[23:50] <stgraber> yeah, I must admit not using backports (as I'm almost never running a stable release) but I'd think the one thing that'd be interesting is co-instability of multiple versions of the backported package and the original package
[23:51] <bdmurray> @pilot out
[23:51] <stgraber> and that's something I can quite easily do, though it'd need quite a bit of work to be user friendly ;)
[23:51] <ajmitch> stgraber: what do you mean by that? having both installed at once?
[23:52] <stgraber> yes
[23:53] <stgraber> anything coming from backport would essentially be isolated from the system so it can't conflict with it (no need for rdepends check then). Some kind of chroot (overlay of your system + the content of the backported packages) would be dynamically created when you ask to start something from backport
[23:53] <ajmitch> stgraber: it sounds like a lot of work just to get a newer version of a package
[23:54] <ajmitch> especially when you want the package in interact with stuff in $HOME
[23:54] <stgraber> ajmitch: how so? my current code gives the program the exact same FS access it'd have otherwise on the FS
[23:55] <stgraber> I guess I confused people a bit by saying "overlay" earlier as I really meant "overlay" and not "copy-on-write overlay" as aufs does
[23:55] <ajmitch> broder: http://paste.ubuntu.com/685665/ is a 5-min plan of what I might do, suggestions welcome :)
[23:56] <stgraber> so any read being done will first it /opt/extras.ubuntu.com/<path requested>, then if not found /<path requested>. Any write would happen directly in / as usual
[23:56] <ajmitch> ok
[23:57] <stgraber> it doesn't restrict the app in any way, other than showing some extra files that arent usually on the fs (or have a different content)
[23:57]  * ajmitch was thinking that you meant you'd keep writes isolated as well
[23:58] <stgraber> no, I do that for stuff I don't trust (in Arkose). Backports are perfectly trustworthy so there's no need to do it
[23:58] <ajmitch> it wouldn't solve the problem of app 2.0 scribbling over 1.x config & data files, but it'd be a good initial step
[23:58] <broder> ajmitch: backportpackage gets more love than prevu these days. i like looking at .desktop files; if there are none i would fall back on trying everything in /usr/bin or /usr/sbin in turn
[23:58] <broder> looks awesome other than that
[23:59] <ajmitch> broder: other bits like the ipv6 address are just PoC implementation details due to my screwy network :)