[00:33]  * SpamapS has 5Mbit upstream and doesn't know what to do with it. :-P
[00:35] <chilicuil> seeding movies? =)
[00:37] <SpamapS> I don't own the copyrights to any movies, so no, that doesn't sound like a good idea.
[00:39] <chilicuil> u dont need to own the copyright since u'll not being doing profit of it, at least that's how it's here (mexico), I was just suggesting n.n
[00:41] <cjwatson> I'm pretty confident that's not how it is where SpamapS lives.
[00:42] <cjwatson> broder: is lintian.ubuntuwire.org stuck?  http://lintian.ubuntuwire.org/tags/preinst-uses-dpkg-maintscript-helper-without-predepends.html shows last updated on Saturday
[00:49] <ion> There are movies you’re free to seed. :-P
[00:50] <RAOF> SpamapS: Back up to U1!
[00:50] <broder> cjwatson: oh yeah, my vm host forgot how to talk to its disks on saturday, and the vm that's running l.uw.o probably didn't come back up. dealing...
[00:52]  * cjwatson sings the I-hate-threads song
[00:52] <cjwatson> it goes "la la la I hate threads"
[00:52] <ion> Sounds more like you hate sucky implementations of threads.
[00:52] <cjwatson> nope, I hate threads
[00:52] <cjwatson> unless you mean the "process" implementation
[00:53] <cjwatson> which hardly counts given the lack of shared data :)
[00:53] <SpamapS> everybody sings that song, until they deal with twisted, then they start stalking their old crazy lover, threads.. hiding in the bushes.. following threads to work..
[00:53] <ion> Not sharing mutable data directly is an impotant part of threads sucking, yes.
[00:53] <ion> err
[00:53] <ion> s/threads sucking/a non-sucky implementation/
[00:54] <RAOF> cjwatson: I'm currently singing the I-hate-posix-signals song.  I WIN!
[00:54] <cjwatson> RAOF: I'm dealing with signals *and* threads
[00:54] <cjwatson> who wins now?
[00:54] <RAOF> Ok, you win.
[00:54] <broder> nobody
[00:54] <broder> nobody wins
[00:55] <cjwatson> (I don't even actually want to use threads myself, but somebody wants this library to be thread-safe ...)
[00:55] <broder> cjwatson: the vm is back up and running an update. new results should be posted within the next couple of hours
[00:55] <cjwatson> broder: great, thanks
[00:55] <RAOF> cjwatson: Isn't the basic premise: {threads, signals} - pick one?
[00:55] <broder> thanks for mentioning it. i've gone ahead and set this vm to autostart, so maybe it won't happen again
[00:56] <cjwatson> I think that with extreme care it is possible to make them interoperate in this very specific case
[00:56] <slangasek> I thought it was pick none
[00:57] <cjwatson> specifically use the self-pipe trick to wake up all threads that are sitting in select any time the signal in question is delivered to any of them, and ensure that any of those threads is capable of handling whatever ensues
[00:58] <cjwatson> you can get away with it if (as a friend pointed out) you *both* block the signal in question and take out a mutex around any manipulation of process-wide state
[00:58] <cjwatson> but it's hairy as all hell
[00:58] <broder> cjwatson: is this for libpipeline/SIGCHILD? does something like signalfd make this better?
[00:58] <cjwatson> yes, and signalfd doesn't really help much
[00:59] <broder> oh hmm, yeah, i see
[00:59] <cjwatson> you could avoid self-pipe that way but you still have to do the extreme-care-for-process-wide-state bits
[01:00] <cjwatson> I think it would be an optimisation at best
[01:06] <SpamapS> cjwatson: well behaved libraries and threaded programs don't keep much process wide state though. :)
[01:07] <cjwatson> SpamapS: Yes, but you have no choice when you have to interact with process-directed signals.
[01:08] <SpamapS> cjwatson: indeed, signals are to threads as bowling balls are to pristine windless lakes early in the morning.
[01:12] <slangasek> SpamapS: that's far too poetic :)
[01:12] <slangasek> TREllis: gconf 3.2.3-3 merged
[01:17] <SpamapS> sigstop from upstart, you just want to trace my forks, forever wait for my fork      bug 406397
[01:17] <SpamapS> damnit, I meant forever you wait
[01:18] <SpamapS> sigstop from upstart, you just want to trace my forks, forever you wait      bug 406397
[01:18]  * SpamapS decides to do haikus only on bugs that are Triaged and > 1 year old from now on
[01:20] <broder> can we make that a bug filing requirement? i think having all bug titles in the form of haikus would be awesome. or at least interesting
[01:21] <cjwatson> the changelogs for debconf 0.9.10 and 0.9.11 are such that I've never bothered trying to beat them
[01:22] <cjwatson> "I updated the / Dutch translation (or rather, / some Dutch guy did -- thanks)."
[01:22] <SpamapS> those are epic
[05:51] <pitti> Good morning
[06:42] <rickspencer3> pitti, more beer this morning!
[06:42] <pitti> :-D
[06:42] <rickspencer3> wow, and the smoke tests look good too
[06:43] <pitti> upgrades are still poor, though
[06:47] <slangasek> mvo has been making progress on the apt issues there
[06:47] <pitti> I'll have a look into the other issues RSN (kdebase, the opencv breaks)
[07:54] <dholbach> good morning
[07:56] <jalcine> Morning, dholbach
[07:57] <dholbach> hey jalcine
[08:54] <TREllis> slangasek: brilliant! Thanks!
[10:02] <lenios> how would you recommend overriding a setting set in a /usr/share/glib-2.0/schemas/*.gschema.override file? (for example org.gnome.desktop.background)
[10:03] <lenios> i don't like the idea of modifying the file from gsettings-desktop-schemas package, and writing another override file doesn't work
[10:31] <dholbach> lenios, you might want to ask in #ubuntu-desktop
[10:59] <angeloc> james_w: I'm intrested in solving bug 830110, can you help me? I'm relatively new to ubuntu contribution
[11:10] <pitti> mvo: hm, I went through https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-desktop/lastFailedBuild/ARCH=amd64,LTS=lts,PROFILE=ubuntu,label=upgrade-test/artifact/lts-ubuntu-amd64/apt.log
[11:11] <pitti> mvo: and I'm still unable to see what it complains about; there seems to be a lot of problems with python:amd64, but I went through all of them, and I don't see a particular reason why it's held back?
[11:15] <mvo> pitti: let me have a look
[11:17]  * pitti wishes that he could peek into mvo's brain to see what he's looking for
[11:20] <zyga> hi
[11:21] <pitti> mvo: hm, the upgrade succeeded on i386, so perhaps it was just due to i386/amd64 buildd skew and the resulting uninstallability?
[11:21] <zyga> I've reported a bug on the software center: https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/947899
[11:21] <zyga> can someone check if this affects other locale (I've tested this on pl_PL)
[11:21] <zyga> it could be broken translation or some kind of unrelated bug/race (it's not 100% reproducible for me)
[11:22] <pitti> mvo: similar with oneiric-main; so let's wait for the next run for now, and assume it was buildd skew
[11:23] <zyga> mvo: https://launchpadlibrarian.net/95596771/software-center-empty-button-bug.png (if you have the time)
[11:27] <pitti> mvo: so I think somewhere in http://paste.ubuntu.com/871292/ (small except) the reason for update-manager removal is hidden
[11:27] <pitti> mvo: am I right that the first "Broken" block was resolved successfully? (until line 19)
[11:28] <pitti> mvo: so I don't understand the complaint from lines 20 to 22
[11:33] <mvo> pitti: the catch is "Investigating (3) software-properties-gtk [ amd64 ] < 0.75.10.2 -> 0.82.4 > ( gnome )
[11:33] <mvo> Broken software-properties-gtk:amd64 Depends on python [ amd64 ] < 2.6.5-0ubuntu1 -> 2.7.2-9ubuntu2 > ( python ) (< 2.7)
[11:33] <mvo>   Considering python:amd64 1269 as a solution to software-properties-gtk:amd64 10000
[11:33] <mvo>   Added python:amd64 to the remove list"
[11:33] <mvo> pitti: I think :)
[11:34] <pitti> mvo: hm, s-c-gtk does not look any different than other python stuff
[11:34] <pitti> Depends: python2.7, python (>= 2.7.1-0ubuntu2), python (<< 2.8)
[11:34] <pitti> looks fairly normal?
[11:34] <pitti> mvo: there's a ton of similar messages there
[11:35] <pitti> mvo: wrt. http://paste.ubuntu.com/871292/, I just ran through the log to find why it's refusing to install/update python-gobject, but I don't find anything
[11:35] <pitti> mvo: let's look at the i386 logs (the one I took the paste from), yesterday's GNOME updates broke amd64 installability temporarily
[11:36] <pitti> mvo: i. e. https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-desktop/lastFailedBuild/ARCH=i386,LTS=lts,PROFILE=ubuntu,label=upgrade-test/artifact/lts-ubuntu/apt.log
[11:36] <pitti> mvo: but perhaps start with the pastebin, that's only 30-is lines and easier to see?
[11:36] <mvo> ok, I check the i386 one now
[11:36] <pitti> (I might have caught the wrong ones, of course)
[11:37] <pitti> oh, found it
[11:37] <pitti>   Considering python-gi:i386 114 as a solution to python-gobject:i386 56
[11:37] <pitti>     Reinst Failed because of libglib2.0-0:i386
[11:37] <pitti>     Reinst Failed because of libgirepository-1.0-1:i386
[11:37] <pitti>     Reinst Failed because of python-gi:i386
[11:37] <hrw> dholbach: thanks for comment on my MOTU application
[11:37]  * pitti drills down the chain
[11:38] <dholbach> hrw, anytime :-)
[11:38] <mvo> pitti: what is the parent of this ? I look at i386,lts,ubuntu,upgrade,test (precise-upgrade-lucid-desktop) and that is a pass for me
[11:39] <mvo> I mean, it failed becuase of test failures, but the actual upgade was fine
[11:39] <pitti> mvo: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-desktop/lastFailedBuild/
[11:39] <pitti> and then i386
[11:39] <mvo> aha, thanks!
[11:40] <mvo> indeed, jenkins confused me
[11:40] <pitti> Broken libglib2.0-0:i386 Breaks on gnome-control-center [ i386 ] < 1:2.30.1-0ubuntu2 -> 1:3.3.90-0ubuntu5 > ( gnome ) (< 1:3)
[11:40] <pitti>   Considering gnome-control-center:i386 27 as a solution to libglib2.0-0:i386 3189
[11:40] <pitti>   Upgrading gnome-control-center:i386 due to Breaks field in libglib2.0-0:i386
[11:40] <pitti> mvo: ^ this is a success, right?
[11:40] <mvo> yes
[11:41] <pitti> but further down
[11:41] <pitti> Investigating (2) libglib2.0-0 [ i386 ] < 2.24.1-0ubuntu1 -> 2.31.20-0ubuntu1 > ( libs )
[11:41] <pitti> Broken libglib2.0-0:i386 Breaks on gnome-control-center [ i386 ] < 1:2.30.1-0ubuntu2 -> 1:3.3.90-0ubuntu5 > ( gnome ) (< 1:3)
[11:41] <pitti>   Considering gnome-control-center:i386 10000 as a solution to libglib2.0-0:i386 2690
[11:41] <pitti>   Holding Back libglib2.0-0:i386 rather than change gnome-control-center:i386
[11:41] <pitti> isn't that the very thing it just looked at, and now decides it's suddenly broken?
[11:41] <mvo> pitti: "  Removing aptdaemon:i386 rather than change python-aptdaemon:i386" <- this one looks fishy
[11:42] <pitti> so in that log it holds back a ton of packages due to libglib2.0-0
[11:42] <pitti> which holds back python-gi, which holds back python-gobject, which probably also cuases the aptdaemon failure?
[11:42] <pitti> mvo: ^
[11:43] <mvo> aha, ok
[11:43] <mvo> yes, make sense, I'm not that far inth elog yet
[11:44] <pitti> mvo: so I'm currnetly wondering why libglib2.0-0 gets held back
[11:44] <pitti> mvo: especially with above two snippets (the breaks: on control-center)
[11:44] <pitti> which first was happy, and the second time not
[11:45] <mvo> pitti: is this one here: Broken gnome-control-center:i386 Depends on gnome-icon-theme-symbolic [ i386 ] < none -> 3.2.2-1 > ( gnome )
[11:45] <mvo>   Considering gnome-icon-theme-symbolic:i386 2 as a solution to gnome-control-center:i386 27
[11:45] <mvo>   Removing gnome-control-center:i386 rather than change gnome-icon-theme-symbolic:i386 <-ok?
[11:45] <pitti> uh?
[11:46] <pitti> mvo: I don't see why the two would collide; control-center depends on icon-theme-symbolic
[11:46] <pitti> gnome-icon-theme-symbolic:i386 Depends on gnome-icon-theme [ i386 ] < 2.28.0-1ubuntu1 -> 3.3.91-0ubuntu1 > ( gnome ) (< 3.3) can't be satisfied!
[11:47] <pitti> mvo: we updated both to 3.3 today, but yesterday they were both at 3.2
[11:48] <mvo> pitti: so just a issue that the archive was out-of-sync?
[11:48] <pitti> mvo: it should have been fine at the time when this ran
[11:48] <pitti> mvo: well, icon-theme anyway
[11:48] <pitti> mvo: do you see a reason why it refuses to upgrade libglib2.0-0?
[11:49] <pitti> mvo: especially the weird breaks: to control-center?
[11:51] <mvo> pitti: I think what happens is that the removal of gnome-control-center is tried ot be undone because it would mean that ubuntu-desktop gets removed. so it tries to reinstall it, that does not work, so it keeps it, but because of the keep it needs to keep libglib2.0-0 too and that causes a cascade of error - does that sound plausible?
[11:51] <pitti> why would it remove it instead of upgrade? it's a versioned breaks
[11:51] <mvo> pitti: but the original problem (that triggers this) is that the icons can not be installed and therefore gnome-control-center can not be upgraded
[11:52] <pitti> mvo: ah, so that's the second breaks:?
[11:52] <mvo> pitti: it can't upgrade it because of the icon-theme-symbolic dependency that it can not satisfy
[11:52] <pitti> mvo: ah, I see
[11:52] <pitti> mvo: so first it resolves the breaks with an upgarde, then it complains about icon-theme
[11:53] <mvo> pitti: yes, and appears to be the case (it may even be more complicated, I see a message about libgoa-1.0-0 that I don't know what it is)
[11:53] <pitti> mvo: ooh, indeed that test only started 3 hours ago
[11:54] <pitti> mvo: ok, thanks
[11:54] <pitti> mvo: so let's try this again
[11:54] <mvo> pitti: shall I re-run the test with the current archive just to ensure that its not archive-churn?
[11:54] <pitti> mvo: ah, can you?
[11:54] <pitti> mvo: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-desktop/ -> this one
[11:54] <pitti> http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html is currently "Beer"
[11:54] <pitti> so it ought to work
[11:54] <pitti> it did have a lot of stuff this morning indeed
[11:54] <mvo> haha
[11:55] <seb128> pitti, beer at this time?
[11:55] <mvo> maybe we should actually make the tester look at that file before it runs?
[11:55] <seb128> pitti, that might explain why we see some breakages in the afternoons :p
[11:55] <pitti> seb128: our goal is to have beer at all times
[11:55] <mvo> for me it said tea
[11:55] <pitti> mvo: it certainly doesn't make much sense to try and run if ubuntu-desktop is uninstallable
[11:55] <pitti> which is often the case when seb128 upgrades gnome
[11:55] <pitti> he grabs the beer, and swoosh, the archive becomes a mess
[11:55]  * pitti hugs seb128
[11:55] <mvo> s/often/everytime/ ;)
[11:55] <seb128> lol
[11:55]  * seb128 hugs pitti mvo
[11:56]  * mvo hugs seb128
[11:56] <pitti> mvo: I was going to ask jibel to restart it, but if you could?
[11:56] <mvo> ok,lets talk after lunch
[11:56] <mvo> I trigger a manual run now and let you know
[11:56] <pitti> mvo: that test hasn't succeeded in 12 days, so I'm eager to get a run on a known-good archive (which is now0
[11:56] <pitti> mvo: cool, thanks
[11:56] <pitti> mvo: will that appear in jenkins?
[11:56] <mvo> I don't know, jibel will know :) he is the master of the jenkins
[11:57] <jibel> pitti, I was about to restart the test now that icon-theme-symbolic is in the archive. i386 succeeded yesterday
[11:58] <pitti> jibel: ah, merci
[11:58] <pitti> mvo: ok, after lunch we need to talk about another weirdness
[11:58] <pitti> but lunch -> good idea, bbl
[11:58] <pitti> jibel: so I guess mvo already started it now
[12:01] <jibel> pitti, right, i386 is running and upgrading. I'll re-run from jenkins when it's finished to publish the resutls
[12:04] <sladen> pitti: scour.  Currently it only Suggests: python-rsvg, python-cairo.  However both of these are needed dependencies for 'cmpsvg' otherwise it shrug and gives up
[12:05] <sladen> pitti: this means that during build scour is run by the exercise is pointless(?)
[12:05] <sladen> pitti: what's your preferred.  Move those to Recommends:/Depends: ?
[12:05] <sladen> pitti: or pull in those two as dependenices in indivudal packages?
[12:06] <sladen> pitti: hold on, you've answed this at  https://bugs.launchpad.net/ubuntu/+source/ubuntu-mono/+bug/927606
[12:23] <jibel> pitti, mvo i386 passed, re-running with jenkins now
[12:52] <pitti> slangasek: we can't add them as recommends, it creates recursive build depends loops
[12:52] <pitti> sorry, sladen ^
[12:52] <pitti> sladen: packages which have a lot of svgs, such as icon themes, need to b-dep on those themselves
[12:56] <pitti> jibel: ah, taht seems to be https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-desktop/53/ ?
[12:56] <pitti> jibel: or was that mvo's manual job?
[12:57] <pitti> jibel: anyway, amd64 passed, and i386 test failure, nice
[12:57] <pitti> jibel: is the x server test a race condition in the tests?
[12:57] <pitti> I see this quite often
[12:59] <pitti> jibel: I'm filing a bug for the libreoffice-common failure in https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-oneiric-universe/lastFailedBuild/ARCH=i386,LTS=non-lts,PROFILE=universe,label=upgrade-test/artifact/universe-i386/apt-term.log
[13:03] <jibel> pitti, that's bug 916291 Sweetshark fixed yesterday
[13:03] <pitti> jibel: oh, that's why I didn't see it
[13:03] <pitti> jibel: thanks, duplicating
[13:03] <pitti> jibel: ok, so looking forward to the next run :)
[13:04] <pitti> jibel: so I'll trawl through the lucid-universe apt log now; it seems the failures of all other tests are already fixed or in progress
[13:11] <pitti> roaksoax: any progress on bug 840406?
[13:11] <pitti> roaksoax: python-scapy is in universe, so at this point the new dependency should probably be dropped?
[13:13] <pitti> mvo: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lucid-main/lastFailedBuild/ARCH=i386,LTS=lts,PROFILE=main-all,label=upgrade-test/artifact/lts-main-all/apt-term.log
[13:13] <pitti> mvo: to my untrained eye this looks like another instance of bug 927993, do you agree?
[13:14] <pitti> mvo: or perhaps not? it tries to configure kde-runtime before libsmbclient gets unpacked and configured
[13:18] <bigon> is there a way to tell upstart that we want to track a pid file?
[13:19] <mvo> pitti: indeed, this looks like another order failure, let me try to reproduce first
[13:20] <pitti> mvo: oh, so it's not the same bug?
[13:20] <mvo> pitti: I doubt it but lets see
[13:21] <pitti> mvo: I picked up some of your training and now walk through the apt.log of precise-upgrade-lucid-universe :)
[13:21] <pitti> man, the day that this thing goes green I'm so much having a beer
[13:21] <jalcine> lol
[13:22]  * mvo runs with order code debug enabled to see what he can find out
[13:22] <mvo> pitti: haha
[13:25] <jibel> pitti, this was bug 940396 and it was duplicated to 927993
[13:26] <pitti> jibel: ah, thanks
[13:26] <pitti> mvo: ^ so maybe undupe it, if appropriate?
[13:27] <mvo> pitti: yes, the first bug is about --configure being call on a package that never saw --unpack, the second one is about a package that is configured before all of its dependencies are configured
[13:28] <pitti> mvo: for the second one, I just discovered bug 892630 and commented on it
[13:28] <pitti> with an extraction of the log
[13:28] <pitti> mvo: that seems to be an instance of the second one (forgot to configure library before configuring rdep)
[13:29] <mvo> pitti: yes
[13:29]  * pitti retitles it to something easier
[13:29] <pitti> mvo: so we should undupe bug 940396 and I make 892630 a dupe of it (or the other way round)?
[13:29] <mvo> pitti: but that is not reproducable via some upgrade test run, right? that was a user reported problem?
[13:29] <pitti> mvo: yes, 892630 was a user report
[13:30] <pitti> mvo: 940396 is from jenkins
[13:30] <mvo> pitti: sounds good to me, maybe 940396 as its actually possible to reproduce this error
[13:30] <pitti> mvo: ack
[13:30] <mvo> 940396 as the master I mean
[13:30] <mvo> ta
[13:31] <pitti> done
[13:33] <pitti> ok, I think all current upgrade failures are covered with bug reports then
[13:34] <pitti> and I think it's mostly these two apt bugs now
[13:39] <jrgifford> I'm attempting to submit a fix for this bug, and following the instructions jbicha gave me have proved... less than fruitful. https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/771375
[13:40] <mvo> pitti: meh, the main-all takes forever to run :/
[13:41] <pitti> mvo: :/ 8.5 hours on jenkins :/
[13:42] <mvo> "fun"
[13:57] <mvo> pitti: it looks ike its a dependency loop problem, but it still should not fail like this
[14:09] <jibel> pitti, I ran oneiric universe again and libreoffice 1:3.5.0-2ubuntu1 is still failing to upgrade. same error
[14:13] <lynxman> packaging question, I'm trying to copy the config files I have working in the debian/conf/* directory on a package that doesn't have an install file, the rules file looks like this http://pastebin.ubuntu.com/871481/
[14:13] <lynxman> line 22 is the one I added, I know cp is not the right one, I tried install -p -d -D -m 0755 but didn't work, for config files what would be the recommended best way?
[14:18] <seb128> pitti, apw: help on bug #947748
[14:19] <seb128> do you know guys know how to debug that?
[14:19] <seb128> is there a known kernel issue?
[14:19] <james_w> angeloc, I'm not sure I know what to do with that bug. Was there a particular reason you asked me?
[14:20] <apw> seb128, there might have been something to do with macs in the -18 kernel
[14:20] <seb128> apw, right, those are macs users
[14:21] <apw> massocists all
[14:21] <apw> seb128, am discussing on #ubuntu-kernel
[14:21] <seb128> apw, thanks, I'm going to lurk there ;-)
[14:22] <Laney> I noticed that my macbook no longer sleeps if I just shut the lid on the newest kernel
[14:22] <Laney> guess that is part of this.
[14:22]  * Laney goes to lurk there too
[14:26] <cjwatson> dpm: could you see if a Chinese translator could review stgraber's suggestion for https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/892386/comments/5 ?
[14:29] <angeloc> james_w: because you are the one who created the source package, sorry if it was a problem
[14:33] <dpm> cjwatson, pinged translators and I'll follow it up
[14:33] <dpm> thanks for the heads up
[14:34] <cjwatson> ta
[14:40] <dpm> cjwatson, stgraber, the Chinese translators didn't seem to happy about adding a shortcut on the translation where there isn't one in the original string. I've asked them to comment on the bug
[14:42] <pitti> mvo: what is a dependency loop problem?
[14:42] <pitti> jibel: ah, so we should reopen this?
[14:42] <cjwatson> I kind of wonder why we don't have a shortcut on that msgstr to match GTK, in some ways
[14:42] <cjwatson> maybe it's also used in the KDE frontend though?
[14:43] <jibel> pitti, I reopened it.
[14:44] <jibel> Sweetshark, ^ bug 916291
[14:44] <stgraber> dpm: I can definitely understand that, though the reason for the bug is that they added it for all the other ones in gtk ...
[14:44] <stgraber> dpm: so they should either add the shortcut for that one too or remove all of these they added for all the gtk stock buttons
[14:44] <stgraber> dpm: otherwise you get an inconsistent installer UI
[14:46] <dpm> stgraber, I'm not sure I quite follow why the shortcut appears in one button and not in the other. Is it because the Back one is stock and thus has a shortcut, and the Continue one is not stock and doesn't have one?
[14:47] <dpm> if so, would it not be better to add a shortcut in the Continue button in the source code?
[14:48] <cjwatson> stgraber: well, no, the "Continue" string is in ubiquity proper but the others are imported from GTK
[14:49] <mvo> pitti: the one in the bugreport? well, that its not resolved correctly :) I think the loop in itself is ok and is resolvable afaict
[14:49] <pitti> mvo: I mean, if we could break a loop somewhere, that might help, but I didn't see a loop dependency on either glib or libsmbclient
[14:50] <mvo> pitti: its kde-runtime, glib is fine
[14:50] <cjwatson> dpm,stgraber: yeah, on inspection, this string is shared with KDE which I'm fairly sure has different shortcut conventions
[14:50] <mvo> pitti: and libkrb5
[14:50] <cjwatson> so I don't think it can be as simple as adding _, even in the translation
[14:51] <mvo> pitti: well, I'm not sure, we could workaround it, but  I prefer to see it  be fixed in libapt
[14:51]  * cjwatson tries to remember why the stock labels weren't good enough
[14:52] <cjwatson> It would read "Forward" rather than "Continue"
[14:52] <roaksoax> pitti: Hi! yes I'm going to take care of that bug this week. Thanks for the reminder!
[14:52] <cjwatson> but it does seem illogical to use stock labels for one thing and not another, in the same button bar
[14:52] <pitti> roaksoax: thank you!
[14:52] <cjwatson> maybe check with mpt?
[14:55] <cjwatson> our back/forward button handling doesn't look desperately consistent in general
[14:55] <sconklin> @pilot in
[14:55] <sveinse> In ext[4] rootfs, when is the "Last mount time" updated? Will it be updated on umount e.g. shutdown, or just mount/startup?
[14:55] <mpt> dpm, I don't know why the stock string was never changed. Probably because it was inappropriately shared with (for example) the navigation buttons in browsers, where you do want just "Back" and "Forward"
[14:58] <dpm> mpt, what do you think the best way to solve that bug and be consistent should be? Both stock buttons with shortcut, or both non-stock buttons?
[15:01] <mpt> dpm, I think the best way would be to make the keyboard combo for going to the next step Enter, and the keyboard combo for going to the previous step Esc.
[15:02] <Sweetshark> jibel: k, thx
[15:04] <dpm> mpt, cjwatson, that's probably a solution for +1, though, right? ^ Is there anything that can be done at this point in the cycle, or should the bug be wontfix for oneiric and precise?
[15:06] <Sweetshark> pitti: any idea what in http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=blob;f=libreoffice-common.postinst.in;h=f2995c1058c96f1ed123ac0d1211a7a75ac8f395;hb=d596b0cbdc3ce6e18ff0201c5dc6b231dfb13a4c could trigger bug 916291? I dont even see anything UNOy being touched there ....
[15:07] <pitti> Sweetshark: what does #INCLUDE_SHELL_LIB# expand to?
[15:08] <Sweetshark> http://anonscm.debian.org/gitweb/?p=pkg-openoffice/libreoffice.git;a=blob;f=shell-lib-extensions.sh;h=21dafe32323e261d0943bcb99cb2429b9aab0602;hb=d596b0cbdc3ce6e18ff0201c5dc6b231dfb13a4c
[15:08] <pitti> Sweetshark: btw, that postinst.in is wrong -- dpkg-maintscript-helper MUST NOT be placed within a $1 check
[15:09] <cjwatson> mpt: I thought that was in general the case anyway, but it's not very discoverable so people missed it
[15:09] <pitti> Sweetshark: well, in postinst you might get away with it, but it's still wrong conceptually
[15:09] <pitti> Sweetshark: as dpkg-maintscript-helper also does stuff on other values of $1
[15:09] <pitti> Sweetshark: so, presumably it's the dpkg-trigger /@OODIR@/share/extensions
[15:09] <pitti> Sweetshark: which causes an unopkg call
[15:09] <pitti> Sweetshark: there might not be a locale set at this point?
[15:10] <pitti> or one that it doesn't like?
[15:11] <Sweetshark> as for dpkg-maintscript-helper, that was cjwatson IIRC.
[15:11] <Sweetshark> cjwatson, pitti: ubuntu veteran fight!
[15:11] <cjwatson> uh, no, but on the phone
[15:11] <mpt> cjwatson, if something isn't discoverable, I try to make it more discoverable before adding a second thing :-)
[15:11] <cjwatson> will get back to you in a bit
[15:12] <pitti> Sweetshark: for dpkg-maintscript-helper it's easiest to use debian/package.maintscript (see man dh_installdeb), that'll remove any remaining doubt; )
[15:12] <pitti> Sweetshark: but anyway, it's not the cause for this bug, it just caught my eye
[15:16] <cjwatson> I thought that's what I suggested for LO
[15:17] <cjwatson> oh, no
[15:17] <cjwatson> it was a bit awkward I think
[15:17] <cjwatson> I think there were ordering concerns
[15:18] <Sweetshark> hmm, so its that the share/extensions trigger (which I moved to -core) firing. However in the log provided from the jenkins-qa there does not seem to be any libreoffice-core action happening at all, so how can a trigger by it do any harm (shouldnt be there yet).
[15:18] <pitti> cjwatson: I suppose .maintscript expands into #DEBHELPER#?
[15:28] <cjwatson> pitti: yes
[15:28] <pitti> so that could just be moved earlier if necessary
[15:28] <cjwatson> pitti: .maintscript definitely isn't mandatory though - I converted dozens of packages, most of them could be handled with .maintscript, but a handful couldn't and I do think that's OK
[15:29] <pitti> cjwatson: oh, absolutely, I was just pointing out that it makes things easier
[15:29] <cjwatson> and I think it's better to not use .maintscript if the alternative is moving code around in ways that we aren't entirely certain of
[15:29] <pitti> cjwatson: the thing that is wrong is putting dpkg-maintscript-helper into an if [ $1 = ... ]
[15:29] <pitti> it might be harmless in a postinst (as at that point you can't roll back any more)
[15:29] <pitti> but it is actively breaking stuff in preinst and prerm
[15:30] <cjwatson> sure
[15:30] <cjwatson> contrary to what Sweetshark says though, I didn't put it there
[15:30] <cjwatson> the most you can pin on me is that I failed to move it out of there :)
[15:31] <cjwatson> my change was to remove 'dpkg-maintscript-helper supports' guards and the like, which do more harm than good
[15:31] <pitti> *nod*
[15:31] <pitti> Sweetshark: so, we violently agree :)
[15:31] <pitti> no fight, sorry
[15:32] <ogra_> bah
[15:32]  * ogra_ puts away the popcorn
[15:32] <L3top> can anyone explain to me how "Select best server" works? Or better yet, just point me to the code.
[15:35]  * Sweetshark grabs ogra_ s popcorn and runs.
[15:35] <AnAnt> how can I test upgrade from lucid to precise ?
[15:35] <ogra_> haha
[15:36] <mvo> can someone with a nvidia (either free or proprietary) run  "python /usr/share/pyshared/debtagshw/opengl.py " and tell me the renderer string please? same for the fglrx driver please :) ?
[15:37] <mvo> (on precise I should add)
[15:37] <L3top> was just gonna say...
[15:37] <broder> who's the language-selector expert? there are 2 mp's that have been sitting around for a while that i don't know how to evaluate (https://code.launchpad.net/~debfx/ubuntu/precise/language-selector/kubuntu/+merge/92967 and https://code.launchpad.net/~jincreator/ubuntu/precise/language-selector/korean/+merge/93535)
[15:39] <james_w> angeloc, ah, that's an artefact of the way Launchpad reports these things, I don't actually know anything about that package
[15:39] <james_w> angeloc, smspillaz might be a good person to talk to as he commented on the bug
[15:39] <Sweetshark> pitti: what is the canonical way to find out if another package is installed in a postinst script?
[15:41] <pitti> Sweetshark: not sure whether there is THE  canonical way, but I believe "dpkg -s coreutils | grep ^Status" should give you the status
[15:41] <pitti> Sweetshark: that'll tell you if it's uninstalled, unpacked, or configured
[15:43] <Sweetshark> jibel: can you tell me if libreoffice-core was installed before this update was run, and if so at which version?
[15:46] <jibel> Sweetshark, from dpkg.log 1:3.4.4-0ubuntu1 was installed
[15:47] <jibel> Sweetshark, correction that's libreoffice-common
[15:47] <jibel> libreoffice-base-core was installed
[15:47] <jibel> 1:3.4.4-0ubuntu1
[15:47] <Sweetshark> jibel: but no libreoffice-core?
[15:47] <cjwatson> pitti: please don't use dpkg -s in a postinst
[15:48] <pitti> cjwatson: dpkg-query ok?
[15:48] <cjwatson> if you must, use dpkg-query instead, but I'm not certain it's reliable in a maintainer script
[15:48] <jibel> Sweetshark, and libreoffice-core 1:3.4.4-0ubuntu1
[15:48] <cjwatson> I *think* these days it might be; it used to be that dpkg wasn't re-entrant, in that the status file on disk wasn't necessarily up to date
[15:48] <cjwatson> but generally if you have to do that it's the sign of a design error anyway
[15:49] <pitti> Sweetshark: does the "cannot determine language" error message correspond to any code in unopkg itself? it might check the locale which might be invalid during the dist-upgrade
[15:50] <jibel> Sweetshark, list of libreoffice-* packages installed before upgrade: http://paste.ubuntu.com/871618/
[15:53] <Sweetshark> pitti: unopkg uses a _lot_ of libreoffice infra. calling it halfway through the install is icky.
[15:53] <Sweetshark> jibel: thanks.
[15:53] <pitti> Sweetshark: so perhaps the trigger should be made robust against failures, and the postinst configure then does another call (at a point when all dependencies are configured and unopkg has a better chance of working)
[15:54] <pitti> Sweetshark: in general, triggers can be (and often are) called when packages are unpacked but not configured
[15:55] <Sweetshark> pitti: But I still wonder which trigger is actually called there: -common 3.4.4-0ubuntu1 should be gone, -common 3.5.0-2ubuntu1 has no does not provide a tigger action, it just fires it, -core 3.4.4-0ubuntu1 has no trigger action, -core 3.5.0-2ubuntu1 is not installed yet. so where does the trigger action come from?
[16:00] <Sweetshark> pitti: so "the trigger should be made robust" *confused* which one?
[16:04] <mhall119> mvo: ping
[16:04] <mhall119> mvo: did you have a change to look over the edit-patch MP from yesterday?
[16:05] <mvo> mhall119: not yet, I will try to do it next
[16:05] <Sweetshark> pitti: so what I would consider to do: in both -common and -core postinsts, check if we have both a  3.5.X -core and 3.5.0 -common and then and only then trigger the trigger.
[16:06] <ritz> Is it possible to locally build a package for oneiric from bzr branch on precise, using buildeb plugin ?
[16:07] <mhall119> mvo: thanks, I'm working on a blog to get people using it for their quicklist and keyworkds submissions
[16:08] <Sweetshark> jibel: is there a way to recreate that update scenario easily locally (in a VirtualBox or whatever)?
[16:18] <jibel> Sweetshark, you can restore the clone in a VM and reproduce from there
[16:18] <jibel> Sweetshark, http://10.189.74.2:8080/view/Precise%20Upgrades/job/precise-upgrade-oneiric-universe/ARCH=amd64,LTS=non-lts,PROFILE=universe,label=upgrade-test/44/artifact/universe-amd64/apt-clone_system_state.tar.gz
[16:19] <jibel> Sweetshark, hm, try https://jenkins.qa.ubuntu.com/job/precise-upgrade-oneiric-universe/ARCH=amd64,LTS=non-lts,PROFILE=universe,label=upgrade-test/44/artifact/universe-amd64/apt-clone_system_state.tar.gz instead
[16:34]  * Sweetshark just recognized again how awesome mutt is.
[16:35] <Sweetshark> when you edit a mail (what I just did in my todo-folder), it marks the old mails as deleted an creates a new one, thus not confusing other clients.
[16:40] <shadeslayer> mterry: ping
[16:40] <mterry> shadeslayer, yo
[16:41] <shadeslayer> mterry: hey hey!
[16:41] <shadeslayer> mterry: https://bugs.launchpad.net/ubuntu/+source/openal-soft/+bug/586324
[16:41] <shadeslayer> mterry: I'm almost done generating the symbols file and uploading a package to my PPA, could you upload it to the archives?
[16:42] <shadeslayer> ( I don't have upload rights just yet, working on fixing that ;) )
[16:42] <shadeslayer> mterry: packages should appear here : https://launchpad.net/~rohangarg/+archive/experimental
[16:43] <mterry> shadeslayer, ok.  will check back after lunch if they are done building
[16:43] <shadeslayer> mterry: thanks!
[16:43] <mterry> shadeslayer, thanks for patching!  :)
[16:43] <shadeslayer> :)
[16:43] <shadeslayer> derp
[16:44] <shadeslayer> that PPA is full
[16:47] <apw> can anyone tell me what gvfsd-trash's role in the world is?
[17:09] <mali> apw, I would assume it tries to provide underlying services to the file manager say , especially with regards to auto mounted volumes. but thats just a guess
[17:16] <slangasek> bdmurray: you said on 941172 that you pushed a new branch, I don't see changes in lp:update-manager and I don't see a branch listed at https://code.launchpad.net/update-manager/ ?
[17:16] <bdmurray> slangasek: thanks, really pushing now
[17:27] <apw> cjwatson, is it VT7 that has the kernel console output when installing from the liveCD ?
[17:33] <cjwatson> apw: not sure I recall offhand, since the live CD doesn't do the transparent VT thing
[17:35] <apw> cjwatson, thanks, i'll let them search for it :)
[17:42] <pitti> Sweetshark: wouldn't it be easier to add an || true to avoid package installation failure if the trigger fails?
[17:42] <pitti> Sweetshark: and then re-run unopkg in "configure" (i. e. not triggered)
[20:26] <dobey> how does one find a diff of what changed exactly between different debian policy versions? ie, 3.9.2->3.9.3?
[20:27] <micahg> dobey: there's an upgade checklist file in the debian-policy package
[20:30] <SpamapS> can packages in main use -Zxz ?
[20:32] <micahg> SpamapS: as long as you have a Pre-Depends on dpkg >= 1.15.6
[20:32] <micahg> *binary Pre-Depends
[20:33] <micahg> component doesn't matter in this case
[20:33] <SpamapS> micahg: I had thought there was some problem with xz and d-i
[20:33] <micahg> AIUI, it won't improve space on the images, I though that the issues with d-i were fixed, but I guess cjwatson could speak to that point
[20:35] <SpamapS> Please do not use this for packages that are Priority: required or
[20:35] <SpamapS> Priority: important, as you will break the installer if you do (and
[20:36] <SpamapS> http://ubuntu.5.n6.nabble.com/data-tar-xz-support-added-to-Launchpad-td718118.html
[20:37] <micahg> ah, then I guess that the answer is no :)
[20:37] <SpamapS> whois is standard.. so.. should be ok
[20:40]  * micahg thanks SpamapS for the reminder about that
[20:41] <shadeslayer> mterry: so, openal-soft is going to be in main now?
[20:42] <mterry> shadeslayer, once and if archive-admins approve and push it in
[20:42] <shadeslayer> ah ok
[20:45] <broder> micahg: i think -Zxz will improve the server/alternate cds
[20:45] <micahg> right, it's the squashfs it won't help
[20:50] <SpamapS> that reminds me.. I need to un-static-link mysql-client and mysql-server soon
[20:52] <cjwatson> SpamapS: yeah, if you convert something debootstrap has to install to xz, I'll have to revert it, but otherwise it's fine
[20:53] <SpamapS> cjwatson: just to confirm, Priority: standard is ok, yes?
[20:55] <cjwatson> SpamapS: in general, yes.  whois is ok.
[20:56] <cjwatson> build-essential would be bad due to --variant=buildd.
[20:56] <cjwatson> actually no, that's fine, debootstrap can do it in general it's just when it's run in the context of d-i
[20:56] <cjwatson> brain atrophying, apparently
[21:07] <bdrung> iulian, Laney: is there a reason why i should not sync haskell-csv?
[21:09]  * micahg would guess the fact that the whole stack needs to be rebuilt would be a reason to wait
[21:36] <iulian> bdrung: We are gonna get all the Haskell packages sync'ed and thus I think there's no point in syncing it now. We also have to fix the armhf build failure (GHC currently fails to build on that architecture).
[21:37] <bdrung> iulian: k, then i will wait for it
[21:52] <jdstrand> mdz: fyi, since you asked about it before, I filed bug #948481
[21:52] <jdstrand> mdz: sorry
[21:52] <jdstrand> mdeslaur: ^
[21:52] <jdstrand> mdeslaur: that is a master bug with a bunch of tasks for the packages that use dh_apparmor
[21:52] <jdstrand> (that I didn't fix earlier today)
[21:53] <mdeslaur> jdstrand: cool
[22:04] <infinity> SpamapS: You missed the dpkg pre-dep on your whois upload.
[22:04] <dupondje> superm1: there perhaps ?
[22:05] <infinity> SpamapS: See the LP binary upload failure logs.
[22:05] <superm1> dupondje: yeah, what's up
[22:05] <infinity> iulian: Ugh, GHC regressed on armhf?
[22:05] <dupondje> superm1: I dunno if you can forward bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/901410 somewhere internal @ Dell ? :)
[22:07] <superm1> dupondje: ah interesting.  that's one of the new XPS 13's right?
[22:07] <slangasek> infinity: ghc - build regression?
[22:07] <dupondje> well i'm having a XPS 15, seems like somebody else with a XPS 13 has same issue now
[22:08] <seb128> slangasek, hey
[22:08] <slangasek> seb128: hi there :)
[22:08] <infinity> slangasek: Yeah.  Happened last week, I guess, I didn't notice until going through logs today. :P
[22:08] <seb128> slangasek, can you look at bug #948294? I didn't look at it yet but we just got 3 dups and since you did the update..; ;-)
[22:08] <slangasek> seb128: yeah, looking
[22:08] <seb128> slangasek, thanks
[22:08] <superm1> dupondje: ah ok.  well we don't do certification for ubuntu on XPS, but i'll see what we can do about it
[22:09] <dupondje> superm1: I know :) but if it can fixed it would be cool.
[22:10] <dupondje> superm1: its just annoying that I can't disable bluetooth properly now. This eats power ofc :D
[22:15] <slangasek> seb128: hmm, right - so the old gconf2 package is still installed and its trigger is being called, but the underlying libs are apparently in an inconsistent state :(
[22:15] <seb128> slangasek, lack of breaks?
[22:16] <slangasek> maybe
[22:16] <slangasek> not sure if it's better to do that, or to make libgconf-2-4 have a circular dependency with gconf-service
[22:17] <superm1> dupondje: as a temporary workaround you might be able to just disable bluetooth in the firmware if you don't use it much to help with the power eatings
[22:17] <seb128> slangasek, can you get https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/3264443 https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/3264444 to build?
[22:17] <seb128> slangasek, i.e scored up
[22:18] <slangasek> seb128: not a buildd admin
[22:18] <seb128> slangasek, since you are around ;-)
[22:18] <slangasek> infinity can though
[22:18] <seb128> oh, I though you were
[22:18] <seb128> infinity, ^
[22:19] <dupondje> superm1: true. Anyway it would be cool if it could be fixed :)
[22:20] <infinity> seb128: Done.
[22:20] <seb128> infinity, thanks
[22:21] <seb128> infinity, both? the amd64 score didn't change
[22:21] <infinity> seb128: Picky, picky.
[22:21] <seb128> infinity, ;-)
[22:21] <seb128> infinity, now it did!
[22:21] <seb128> thanks ;-)
[22:25] <iulian> infinity: Yea, it was really a surprise to be honest. It seems that janimo` has a fix though. I'm gonna take a look at it as soon as possible if Laney doesn't beat me to it.
[22:25] <infinity> iulian: Oh, shiny.  If Jani's on it, I'll happily ignore it.
[22:29] <mhall119> seb128: is there an easy way to say "Take the last n revisions of this bzr branch, and turn them into a patch instead"?
[22:29] <seb128> mhall119, bzr diff -c <rev> > patch ?
[22:29] <slangasek> bdmurray, infinity: looking at the InstallCmdLine in bug #947738, can either of you tell offhand if this is a CD or USB?
[22:30] <slangasek> mhall119: bzr diff -r -$((n+1)) > patch
[22:30] <mhall119> seb128: I meant a package patch
[22:30] <seb128> no
[22:30] <slangasek> bzr diff -r -$((n+1)) > debian/patches/patch? :)
[22:30] <mhall119> will a bzr diff work for a quilt patch?
[22:31] <slangasek> yes, it's the same format
[22:31] <mhall119> oh nice, so much easier
[22:31] <slangasek> oh, you should probably do:
[22:31] <slangasek> bzr diff -p1 -r -$((n+1))
[22:31] <slangasek> since quilt really wants -p1 instead of bzr's default of -p0
[22:31] <slangasek> (an unfortunate bzr default, that)
[22:33] <mhall119> so, bzr uncommit; bzr diff -p 1 > debian/patches/patch; bzr add debian/patches/patch; bzr revert; dch -i; bzr commit?
[22:33] <mhall119> like that?
[22:33] <slangasek> you also need to add the patch to debian/patches/series
[22:33] <seb128> mhall119, why uncommit?
[22:33] <mhall119> seb128: to get the patch's changes out of the source
[22:34] <slangasek> so echo patch >> debian/patches/series
[22:34]  * mhall119 is writing for people who have already committed their changes to a bzr branch
[22:34] <slangasek> who's the audience?
[22:34] <mhall119> slangasek: people who have been following my previous blogs about adding quicklists and keywords
[22:35] <slangasek> if this is for new contributors to Ubuntu, I'd rather they just push a merge proposal with whatever changes they've already made...
[22:35] <mhall119> slangasek: you'd be in the minority on that preference I think
[22:35] <slangasek> among Ubuntu developers who'll be merging?
[22:35] <mhall119> well, among people who have been asking me to get them to use edit-patch and submit changes that way
[22:36] <seb128> slangasek, the complain I think that those are inline changes without changelog entry
[22:36] <seb128> slangasek, mostly against the wrong vcs for desktop stuff
[22:36] <seb128> though agree it might be easier to just deal with those by fixing them ourself
[22:36] <seb128> but we shouldn't recommend stuff to keep done this way
[22:37] <slangasek> oh, well, I've never used edit-patch, and it doesn't look like an obvious fit for the UDD workflow at all
[22:37] <ScottK> Some of us still prefer the ways that have nothing to do with UDD.
[22:38] <james_w> mhall119, bzr dep3-patch -r -n..
[22:38] <seb128> slangasek, it's just a wrapper about dpatch-edit-patch and the cdbs quilt equivalents
[22:39] <slangasek> dep3-patch> hunh
[22:39] <slangasek> seb128: yeah... none of those are part of my workflow :)
[22:39] <james_w> I think it might be spelt bzr patch --format something in precise
[22:39] <james_w> jelmer will know of course
[22:39] <mhall119> james_w: bzr: ERROR: command 'dep3-patch' requires argument LOCATION
[22:40] <james_w> oh, you expected my suggestion to work?! :-)
[22:40] <mhall119> james_w: also, bzr patch is for applying patches, according to it's help
[22:41] <james_w> diff I mean, don't I
[22:41]  * jelmer waves
[22:41] <jelmer> there was some talk about integrating 'bzr dep3-patch' back into 'bzr diff --format=dep3', indeed. But it hasn't happened yet.
[22:41] <james_w> ah, ok
[22:42] <james_w> mhall119, try "bzr dep3-patch -r-n..-1 . > debian/patches/whatever"
[22:42]  * mhall119 wants a "bzr patchdeb" that finds the last revision that matches the parent branch, pops them off into a patch, add's their comments to the changelog, and commits the result
[22:42] <mhall119> all I want is everything, is that so much to ask?
[22:42] <jelmer> mhall119: that is mostly what 'bzr dep3-patch' does
[22:43] <jelmer> mhall119: basically, if you run it inside of the package branch and specify the location of the branch with the patch it will do that.
[22:44] <mhall119> jelmer: does dep3-patch only work on uncommited changes?
[22:44] <jelmer> mhall119: no, it only works on committed changes
[22:45] <slangasek> well, if you diff against the current branch and use -r, it should work with both, no?
[22:45] <slangasek> but if they're committed, it's going to be awkward to get them into quilt in a way that makes everything happy
[22:45] <bdmurray> slangasek: I cannot tell
[22:46] <slangasek> you almost might as well use dpkg-source --commit at that point
[22:46] <slangasek> bdmurray: ok, thanks for looking
[22:46] <jelmer> the most interesting thing about dep3-patch is that it tries to generate the DEP-3 header
[22:48] <bdmurray> slangasek: however changelog for usbcreator mentions 'Always write cdrom-detect/try-usb=true' so sounds like a usb stick
[22:49] <slangasek> right
[22:49] <slangasek> that was my best guess
[22:49] <slangasek> and the dupe bug does *not* have this, so looks like a CD
[22:52] <mhall119> alright, I'm not getting how to use dep3-patch
[22:53] <jelmer> mhall119: what are you trying to do exactly?
[22:53] <mhall119> say I have lp:~tcfox54-gmail/ubuntu/precise/gimp/add_quicklist
[22:54] <mhall119> it has 1 revision on top of ubuntu:gimp, rev 51
[22:54] <mhall119> I want to turn rev 51 into a patch
[22:56] <stgraber> mhall119: let me try something quickly
[22:57] <stgraber> once I finished downloading that gimp branch ... isn't exactly light apparently ;)
[22:57] <jelmer> mhall119: here is an example of what I'm using: http://pastebin.ubuntu.com/872184/
[22:57]  * jelmer tries for gimp
[22:57] <mhall119> and just to make things more fun, say this branch has already been pushed to LP and an MP created for it
[22:58] <mhall119> jelmer: so -d is for the unmodified branch, and LOCATION is the modified?
[22:58] <jelmer> mhall119: (yes, though -d defaults to ".")
[22:59] <mhall119> ah, perfect, I had that all backwards it seems
[23:00] <mhall119> so the output of that goes into debian/patches/add_quicklist, echo "add_quicklist" > debian/patches/series, then should I have them remove their changes from the source, or just dch -i and push with both the changed source *and* the patch?
[23:02] <mhall119> is this even worth having people do for existing MPs and branches, or should I just make a tutorial for new contributions?
[23:03] <stgraber> mhall119: alternatively: bzr uncommit && dpkg-source --commit
[23:03] <stgraber> mhall119: assuming you have the .orig.tar.gz in the parent directory
[23:03] <mhall119> stgraber: I'll assume they won't
[23:03] <stgraber> this will prompt you for a patch name, generate debian/series and open vim in your patch so you can set the headers
[23:03] <mhall119> since I instructed them to get things from bzr
[23:03] <stgraber> mhall119: then they can just run bzr bd -S which will generate it from the branch for them
[23:04] <mhall119> again though, is it worth if for the few existing, non-merged branches?
[23:04] <infinity> I'd like to pretend that people changing packages will have the .orig (and, indeed, the previous source version) in their parent.
[23:04] <stgraber> mhall119: actually: bzr bd -e && bzr uncommit && dpkg-source --commit
[23:04] <infinity> Because I sure do love when people obviously didn't debdiff a.dsc b.dsc to see how many undocumented changes they accidentally introduced (or what they dropped)
[23:05] <stgraber> mhall119: that will generate the orig.tar.gz, will uncommit and commit the diff to a patch
[23:05] <mhall119> dpkg-source will do a bzr commit? or just create the patchfile?
[23:05] <infinity> The latter.
[23:06] <mhall119> will it update the changelog?
[23:06] <stgraber> mhall119: it'll take any delta in the source directory and make that a patchfile, creating debian/patches/series if necessary
[23:06] <stgraber> mhall119: it also adds the default patch headers that you just then need to fill
[23:06] <infinity> It won't touch the changelog, no.
[23:06] <stgraber> mhall119: no, it doesn't touch the changelog and won't include changelog changes in the patch because they're fine where they are
[23:07] <stgraber> mhall119: so if yu run: bzr bd -e && bzr uncommit && dpkg-source --commit && bzr add && bzr commit -m "Clean commit this time"
[23:07] <stgraber> you'll have a new commit called "Clean commit this time" replacing your old commit and with the changes in debian/patches instead of inline
[23:07] <slangasek> mhall119: however, there's a 'dep3changelog' helper in devscripts which will take the dep3 patch header and attempt to create a changelog
[23:08] <mhall119> so many options...
[23:08] <slangasek> yes :/
[23:08] <mhall119> ok, gotta run, but thanks everyone, I'll try all of these out and see which one I'm most comfortable writing about
[23:13] <SpamapS> infinity: ACK, fixing
[23:16] <SpamapS> infinity: and thanks.. I was a bit confused by the fail to upload :-P
[23:17] <infinity> SpamapS: There's an upload log that points out why. ;)
[23:17] <SpamapS> Yeah I didn't see that before I ran off to the dentist :p