[00:08] <cjwatson> pitti: hm, I guess I might as well stop bothering to run apt-listchanges on upgrades.  it would be nice to have a replacement for that, since it's a really useful thing to scan on upgrades to see e.g. whether some bug you care about might have been fixed
[00:08] <cjwatson> or, well, not a replacement, but an alternative way for it to fetch its data
[00:17] <tazz> would it be wise to still follow https://wiki.ubuntu.com/DebootstrapChroot ?
[00:17] <tazz> also https://wiki.ubuntu.com/PackagingGuide/Complete
[00:18] <ebroder> tazz: instead of the DebootstrapChroot page you can use the mk-sbuild command in ubuntu-dev-tools
[00:19] <tazz> umm... ok, i'll readup on that. Thanks ebroder
[00:20] <persia> tazz, What are you trying to accomplish?
[00:21] <tazz> persia, trying to learn how to package stuff in ubuntu
[00:21] <persia> New stuff?
[00:21] <tazz> persia, umm not really. just learning for now :)
[00:22] <persia> I think you'll have a more successful experience if you either try to package new stuff you want that isn't available, or try to patch old stuff that doesn't work the way you want.  There's enough docs out there that almost nobody actually understands it all, and it's easy to get lost trying to learn if you aren't focused on some tasks.
[00:23] <persia> Most folk tend to learn enough to do the things they care about, and enough about how to get more info to be comfortable digging up the rest at need (although we're all constantly asking each other for help filling gaps)
[00:25] <tazz> i see... well there is this anoying bug in amarok i would like to see fixed :p
[00:26] <tazz> s/anoying/annoying
[00:26] <persia> Excellent place to start!
[00:26] <persia> So, first steps are to get the source and hunt down the solution.  Do you know how to do those?
[00:28] <tazz> apt-get source amarok ?
[00:28] <persia> Yep.
[01:05] <microcai> g_socket_client_connect_* cause fd leek when connection refused, anyone notice this ?
[06:49] <dholbach> good morning!
[08:24] <hrw> hi
[09:48] <sosaited> I am trying to install automake 1.11 by compiling source on Lucid, but after running make install. When I check with apt-cache policy automake1.11 , I get http://paste.ubuntu.com/524962/
[09:50] <persia> sosaited, That's expected.  If you want to manage software with packages, you will need to create a .deb and then install it, rather than using raw make install.  You can start with `apt-get source automake1.11`; then in the unpacked source `debuild -b` to get an approximate dirty package.  If you need clean distributable packages, ask lots more questions here.
[09:56] <sosaited> persia: Thanks.
[11:22] <chrisccoulson> no doko today?
[11:23] <chrisccoulson> could really use some help with bug 663294 :)
[11:25] <directhex> mmm pie
[11:25] <seb128> chrisccoulson, I think he said he would stay some extra days in florida after UDS
[11:25] <chrisccoulson> seb128 - ah, ok. i guess it will have to wait a few more days
[11:26] <chrisccoulson> directhex, this is the only time i have found pie to be bad ;)
[11:26] <chrisccoulson> pie is usually great
[11:26] <chrisccoulson> :)
[12:29] <ScottK> chrisccoulson: doko is offline this week.
[12:29] <\sh> barry: can I bug you about a python setuptools question? :)
[12:29] <chrisccoulson> ScottK, thanks
[12:29]  * ScottK notes to \\sh that barry is an old man and this is probably too early for him.
[12:30] <\sh> ScottK: at least he'll get a hilight :)
[12:30] <ScottK> Yep.
[12:36] <sebner> ScottK: isn't he following your lead with "sleep is for the weak" .. even though he is old? :P
[12:37] <ScottK> sebner: He's definitely weak (although I ought to note he was doing 6AM Ti Chi (or however you spell it) last week and I wasn't.
[12:37] <ScottK> )
[12:37] <sebner> hahaha
[12:38] <persia> +a
[12:58] <pitti> Good morning
[12:58] <pitti> emgent: at plumber's
[12:59] <stgraber> morning pitti
[12:59] <pitti> cjwatson: I wrote apt-changelog yesterday to retrieve it, haven't integrated it into a package yet
[12:59] <pitti> cjwatson: but an apt-listchanges like replacement should be rather easy -- after all, we know which version is installed and which is the candidate, so it could just crop the downloaded changelog after that
[13:00] <pitti> cjwatson: do you think "apt-changelog --new mypkg" would do? I could also just change apt-listchanges itself
[13:00] <pitti> hey stgraber
[13:02] <pitti> cjwatson: added a WI for me to fix apt-listchanges
[13:03] <pitti> mvo: would it be okay to you if I added apt-changelog to the apt-utils package? and into cmdline/ in the source package?
[13:04] <mvo> pitti: sure
[13:04] <pitti> mvo: ok, thanks
[13:04] <mvo> pitti: why not part of apt-get ?
[13:04] <mvo> pitti: or apt-cache
[13:04] <mvo> pitti: the plan is to add a generic "apt" btw
[13:04] <pitti> mvo: it's a shell script right now, but I don't mind much
[13:05] <mvo> pitti: ok, just add it then
[13:05] <mvo> pitti: I will merge that then
[13:05] <pitti> mvo: oh, ok; I can do a branch (I was going to commit to lp:apt directly, it's u-core-dev owned)
[13:06] <mvo> ok
[13:06] <mvo> either way
[13:06] <mvo> is fine :)
[13:06] <pitti> 'k, thanks!
[13:06]  * pitti -> listen to keynote &
[13:09] <cjwatson> pitti: I think I'd prefer it to be integrated into apt-listchanges, since it already has other nice UI facilities.  Thanks!
[13:26] <corecode> hey
[13:26] <corecode> how do you pull the debian/changelog into the bzr commit message?
[13:28] <cjwatson> debcommit
[13:29] <corecode> thanks
[13:32] <corecode> if i have fixes for a package, should i branch the bzr code and upload them into a private branch?
[13:33] <corecode> W: sqliteodbc source: diff-contains-bzr-control-dir .bzr
[13:33] <corecode> am i using the bzr branches properly?
[13:35] <cjwatson> put DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I" in ~/.devscripts
[13:36] <cjwatson> that will exclude .bzr from the built source package
[13:36] <corecode> thanks
[13:36] <corecode> much appreciated
[13:56] <smoser> cjwatson, are you around ?
[13:57] <cjwatson> smoser: hi
[13:57] <smoser> i've beeen asked a couple times to try and get the pv-grub support back into lucid
[13:57] <smoser> this is fairly easy from a grub-legacy-ec2 perspective, and i've testted general functionality
[13:58] <smoser> the issue that i'm running into is that in our lucid images, we *need* to have 2 kernels.  the -virtual (for booting under UEC/kvm) and the -ec2 kernel (for booting under ec2)
[13:58] <smoser> with these changes, grub2 will run, and see 2 kernels (-ec2 and -virtual)
[13:59] <smoser> the -ec2 is actually numbered > -virtual, so under UEC, grub2 would run, and a reboot would take you into the -ec2 kernel which would fail to boot.
[13:59] <smoser> would you be open to changes that would explicitly ignore certain (-ec2) kernels in the grub2 lucid code ?
[14:00] <cjwatson> if possible, for lucid I'd prefer it if the change could be done in an EC2-specific package, to eliminate the possibility of regressions for non-EC2 users
[14:00] <cjwatson> is there any way to supply configuration to grub2 in this case?
[14:00] <smoser> we wouldn't need it in maverick or natty, as the -ec2 kernel has been removed from the images, so an upgrade would get you a newer -virtual kernel than the -ec2 kernel, so it would then be selected.
[14:01] <smoser> i was expecting you would know more than i do, but i didn't immediately see any way to 'configure' /etc/grub.d/10_linux to ignore certain things.
[14:07] <cjwatson> smoser: I meant, can you feed it a grub.cfg
[14:07] <cjwatson> or anything else in /boot/grub
[14:08] <smoser> well, i can write anything i want in /boot/grub either via cloud-init on first boot, or via the image build process.
[14:08] <smoser> but the goal is to have a normal 'apt-get dist-upgrade' do the right thing (which would run update-grub)
[14:10] <cjwatson> so the problem is with images that have already been created?
[14:10] <cjwatson> can -ec2 kernels ever be usefully booted by grub2, on any system?
[14:11] <smoser> i would say there is a small edge case where someone might have used the -ec2 kernel as a xen domU kernel because it worked for them.
[14:11] <smoser> rather than building their own kernel
[14:12] <smoser> wait, but then grub2 wouldn't be loading it
[14:12] <smoser> grub2 could not be the bootloader for any xen domU that i'm aware of
[14:13] <smoser> so i think its safe to answer your above question with 'No'.
[14:13] <pitti> cjwatson: ack
[14:13] <smoser> cjwatson, the problem would be with future images.
[14:14] <cjwatson> smoser: if grub2 can never usefully load an -ec2 kernel, then I think it's OK to exclude it using a grub2 SRU
[14:14] <smoser> and just exclude it by match in 10_linux ?
[14:14] <cjwatson> please use lp:~ubuntu-core-dev/ubuntu/lucid/grub2/lucid as the bzr branch for such a change - the lucid version uses cdbs-edit-patch
[14:15] <cjwatson> I guess so
[14:15] <smoser> cjwatson, ok. thanks.
[14:15] <cjwatson> if [ "${version%-ec2}" != "$version" ]; then continue; fi  or some such
[14:15] <smoser> right.
[14:16] <cjwatson> er, actually, watch out, that loop has an explicit iterator at the end
[14:16] <smoser> cjwatson, i'll be careful, and you'll review.
[14:16] <smoser> :)
[14:16] <cjwatson> the grotty  list=`echo $list | tr ' ' '\n' | grep -vx $linux | tr '\n' ' '`  bit
[14:17] <smoser> just a bikeshed question, you would prefer 'if [ ... ] ; then continue; fi' to [ ... ] && continue
[14:18] <cjwatson> given that you may have to have a copy of that list= bit before the continue, I think if ... fi would be clearer, yes
[14:18] <cjwatson> (in general I don't mind)
[14:18] <smoser> ok. thanks cjwatson.
[14:19] <cjwatson> np, good luck testing that one ...
[14:52] <cnd> how can I get the info copied into an apport bug summary?
[14:52] <cnd> I don't want to run apport-collect or apport-cli and get all the other extra files
[14:52] <cnd> just that nice summary
[15:21]  * ScottK would appreciate it if someone who has moderator power on the TB list would pay the queue a visit.
[15:25] <cjwatson> ScottK: done
[15:25] <ScottK> cjwatson: Thanks.
[15:32] <ads> Hi all
[15:32] <ads> Ok, who's responsible for the PHP mess in Ubuntu? ;-)
[15:34] <ads> I can't get PHP to log parse errors even though I configured every known option and phpinfo() tells me all options are switched on.
[15:34] <ScottK> ads: You probably want #ubuntu-server.
[15:35] <ScottK> barry: Speaking of python3.2, any idea why it's failing to build on Natty?
[15:35] <ads> pff, #ubuntu just forwarded me here ;-)
[15:35] <ScottK> ads: It's a mistake to come here for support questions.
[15:36] <Pici> ScottK: I'll sort it out with the person who suggested it.
[15:36] <ScottK> Thanks.
[15:42]  * cjwatson idly wonders if we should switch to the perl in experimental
[15:42] <cjwatson> since it's actually vaguely current
[15:42] <cjwatson> then again I'm not sure I want to put lots of time into it
[16:00] <pyghassen> help please
[16:00] <pyghassen> i got this error
[16:00] <pyghassen>  subprocess installed post-installation script returned error exit status 1
[16:00] <pyghassen> subprocess: command not found
[16:05] <ricotz> hi, any reason why the vala 0.11 binaries are still queued?
[16:07] <seb128> ricotz, the queue just need to be reviewed, there is 63 items there
[16:07] <seb128> ricotz, basically people have been busy at UDS, travelling back and jet lagged
[16:07] <seb128> just let some time for people to catch up with everything
[16:08] <ricotz> seb128, ok, just thinking that this might cause some build failures since the current copied version isnt working right
[16:08] <seb128> why not?
[16:10] <ricotz> seb128, glib and gobject-introspection updates, i didnt looked into yet, but it might be the cause for a building problem of dockmanager
[16:10] <seb128> ricotz, things we will sorted in the next days
[16:11] <seb128> it's still early natty so build issues are to expect
[16:11] <seb128> time to land the next versions, merges etc
[16:11] <seb128> I will review the vala in the queue
[16:11] <ricotz> seb128, ok ;), no problem
[16:11] <ricotz> seb128, thanks
[16:12] <seb128> thank you for pointing issues ;-)
[16:18] <cjwatson> cyphermox: would you like to test out an isc-dhcp package before I upload it?
[16:19] <cjwatson> cyphermox: from what I can see, network-manager needs to be rebuilt in order to use dhcp v4?
[16:19] <cjwatson> (which seems like a flaw ...)
[16:19] <cyphermox> cjwatson, yeah, needs to be rebuilt later
[16:19] <cyphermox> it's not ideal, but it will work fine even before rebuild I think
[16:20] <cyphermox> cjwatson : do you have isc-dhcp in a PPA now?
[16:20] <cjwatson> just locally
[16:20] <cjwatson> guess I can stick it in a PPA
[16:22] <cjwatson> oh, um, natty PPAs aren't switched on yet are they ...
[16:22] <cjwatson> let me see if I can get that fixed
[16:22] <cyphermox> cjwatson, what do you mean not switched on? it works for me
[16:23] <cyphermox> or if you point me to a branch I can build it locally and test it now
[16:23] <cjwatson> oh, I looked at https://launchpad.net/~cjwatson/+archive/ppa and it didn't have natty in the drop-down - I guess it only lists the ones you've uploaded to
[16:23] <cyphermox> right
[16:23] <cjwatson> uploading to that PPA now
[16:23] <cyphermox> ok.
[16:24] <cjwatson> before rebuild> it'll use dhclient3, won't it?
[16:24] <cyphermox> cjwatson, I think it will just work, though possibly try to get v6 as well if you don't specify -4 and/or -6
[16:25] <cjwatson> it'll still try to look in /etc/dhcp3/dhclient.conf, from what I can see
[16:25] <cyphermox> cjwatson, it will use dhclient, the main issue was before i patched it to detect the version, NM would fail trying to pass -4 or -6 to dhclient (which couldn't parse that)
[16:25] <cyphermox> cjwatson, I though isc-dhcp still looked at those configs too... but either way, from what I recall the config file to use is passed as a parameter
[16:26] <cjwatson> the postinst copies /etc/dhcp3/dhclient.conf to /etc/dhcp/dhclient.conf on upgrade from dhcp3-client, and thereafter it uses /etc/dhcp/dhclient.conf
[16:26] <cyphermox> ok
[16:26] <cyphermox> well I do pass the config file with -cf
[16:27] <cjwatson> technically you could purge dhcp3-client after upgrade :-)
[16:27] <cjwatson> though I'm not sure if that would delete /etc/dhcp3/dhclient.conf
[16:27] <Chipzz> cjwatson: what does debian policy say about moving the file instead of copying it in such cases?
[16:27] <cyphermox> right
[16:27] <cjwatson> it's not in conffiles any more
[16:27] <cjwatson> Chipzz: nothing
[16:28] <cyphermox> cjwatson, if you want me to test, I can give it a quick shot (though I don't have an ipv6 rig), then it could be ready for upload
[16:28] <cjwatson> cyphermox: if you could - I've tested it just with ifup
[16:28] <cyphermox> I can also upload a newer NM (but not too new) after testing that as well locally, just to be sure everything is good
[16:30] <cyphermox> cjwatson, nice job on libpipeline btw
[16:30] <cjwatson> thanks :)
[16:30] <cjwatson> hopefully some people other than me will start using it
[16:31] <cyphermox> cjwatson, I already have an idea for it
[16:31] <cjwatson> cool, let me know if it exposes any weaknesses in the library
[16:31] <cyphermox> sure
[16:33] <cyphermox> hmm... actually I wonder if it could even be used by NM to do things like finally implementing proper two-factor auth for VPNs (e.g. password changes)
[16:33] <cjwatson> has it been avoiding fork/execve 'cos of the hassle?
[16:34] <cjwatson> didrocks said he was going to look at whether it would be feasible to integrate libpipeline with the glib event loop somehow
[16:35] <cjwatson> which may not always matter, it depends on the circumstances
[16:37] <cjwatson> grr, failed to build
[16:39] <cjwatson> that's odd, libldap2-dev hasn't changed ...
[16:45] <cjwatson> ah, I bet it's a --no-add-needed thing
[17:10] <ScottK> didrocks: When you uploaded gtk-doc-tools it appears you dropped the highlight build-dep, but not the runtime depends so it's now uninstallable.
[17:10] <didrocks> ScottK: urgh, sorry, will fix that right away
[17:10] <ScottK> didrocks: https://launchpad.net/ubuntu/+source/atk1.0/1.32.0-0ubuntu3/+build/2030284 is the result.
[17:10] <ScottK> Thanks.
[17:13] <didrocks> ScottK: uploaded, if you want to give it a higher priority to avoid too many FTBFS… thanks :)
[17:13] <ScottK> didrocks: I can't.  Needs a buildd admin.
[17:13] <didrocks> ScottK: oh, I was thinking archive admin can as well, ok
[17:14] <ScottK> pitti or cjwatson: ^^^ would you please rescore gtk-doc
[17:14] <ScottK> Nope.
[17:14] <ScottK> I can but ask like any other mortal.
[17:14] <Laney> A team which ScottK isn't a member of? Never thought I'd see the day.
[17:15] <highvoltage> Laney: he's gone soft!
[17:15] <ari-tczew> is XS-Python-Version: >= 2.5 okay for Ubuntu ?
[17:19] <ari-tczew> or maybe we should require >= 2.7 since natty?
[17:19] <cjwatson> ScottK: gtk-doc is already successfully built?
[17:19] <ScottK> Maybe it was fast.
[17:19]  * ScottK looks
[17:19] <cjwatson> hmm, ubuntu-build doesn't notice the newer upload
[17:20] <ScottK> It's building now in any case.
[17:20] <cjwatson> damn, lost the opportunity to fix the bug :-)
[17:21] <cyphermox> cjwatson, back from lunch, downloading isc-dhcp now.
[17:22] <cjwatson> cyphermox: 4.1.1-P1-11ubuntu1~ppa2 has built but isn't published yet
[17:22] <cjwatson> though I guess you can get it from LP
[17:22] <geser> ari-tczew: did the package stopped working with older python version or why the bump?
[17:22] <cyphermox> that's what I did
[17:23] <ScottK> ari-tczew: XS-P-V is based on what the upstream source requires.  It should never be changed because of what versions we have in the archive.
[17:24] <ari-tczew> geser: Didn't test. Why added? bug 39196
[17:39] <pitti> ScottK: gtk-doc already built
[17:39] <ScottK> pitti: Yep.  It got there very quickly anyway.
[17:40]  * ScottK should have looked at the build queue before calling for help.
[17:40] <pitti> ScottK: np
[17:41] <pitti> superm1: do you think you can review/approve https://blueprints.launchpad.net/ubuntu/+spec/hardware-desktop-n-package-field-modaliases this week? mostly to confirm that this is what you need?
[17:41] <pitti> mvo: do you have a minute to review/approve https://blueprints.launchpad.net/ubuntu/+spec/packageselection-desktop-n-automatic-printer-driver-download-should-support-signed-packages this week? should be easy
[17:54] <mvo> pitti: sure
[18:13] <cjwatson> cyphermox: any luck?
[18:15] <cyphermox> cjwatson, looks okay, aside from an issue with the apparmor profile
[18:16] <cjwatson> cyphermox: oh?
[18:16] <cyphermox> can't create the lease file, hold on
[18:17] <cjwatson> odd
[18:17] <cjwatson>   /var/lib/dhcp/dhclient* lrw,
[18:17] <cyphermox> ah
[18:18] <cjwatson> (used to be /var/lib/dhcp3/)
[18:18] <cyphermox> that's why I'll need to recompile NM I think :?
[18:18] <cjwatson> could be
[18:18] <cyphermox> I'm sure
[18:18] <cyphermox> the error was with /var/lib/dhcp3
[18:18] <cjwatson> ah, yes, NM_DHCLIENT_LEASE_DIR
[18:19] <cjwatson> I wonder if isc-dhcp-client needs to Breaks: old versions of n-m, or if it won't matter
[18:20] <cyphermox> It doesn't seem to break negotiation, it's just that I expect the lease re-neg might not work properly
[18:20] <cjwatson> seems odd that network-manager has no package relationship at all with dhcp3-client/isc-dhcp-client
[18:21] <cjwatson> despite having compiled-in assumptions about it
[18:22] <cyphermox> well, I added that because the newer branch was done with only isc-dhcp4 in mind.. I had to patch NM to try and cope with v3
[18:22] <cjwatson> right, but shouldn't it depend on the one it's built for or something?
[18:23] <cyphermox> I guess so. I think there was a bug in the past about not depending on dhcp though :)
[18:23] <cjwatson> joy
[18:23] <cyphermox> With isc-dhcp I could get rid of this stuff now
[18:23] <cjwatson> my basic worry here is about partial upgrades from maverick to natty, for whatever reason
[18:23] <cjwatson> we may not have to worry about it right now, but I would like us to think about it
[18:24] <cyphermox> cjwatson, if I add a Recommends now, would that
[18:24] <cyphermox> be sufficient?
[18:24] <cjwatson> wouldn't really make any difference
[18:24] <cyphermox> well, it could pull in isc-dhcp
[18:24] <cjwatson> Recommends affects what's initially selected for dist-upgrade and such but is otherwise advisory
[18:25] <cjwatson> that's going to happen with the new version anyway since dhcp3-client is now a transitional package depending on isc-dhcp-client.  A Recommends is weaker than that
[18:25] <cyphermox> ok
[18:25] <cjwatson> the problem is, what happens if somebody does say 'apt-get upgrade' which only pulls in the new network-manager but won't pull in the new isc-dhcp-client (because it's a new package and 'apt-get upgrade' won't do that)
[18:26] <cyphermox> ah
[18:26] <cjwatson> sure, we can say "don't do that then" but really the package relationship fields ought to forbid it
[18:26] <cyphermox> well, NM still works with dhcp4 though... just the lease stuff is broken. Unsure of what the other impacts might be
[18:26] <cjwatson> ideally it should be impossible to install the old n-m with the new isc-dhcp-client, or the new n-m with the old dhcp3-client
[18:27] <cjwatson> we could do that by versioned Breaks each way, perhaps
[18:27] <cyphermox> I'm happy to set this up for testing in the NM ppa for natty
[18:27] <cjwatson> so n-m Breaks: dhcp3-client (<< 4)  (note you need the version here to exclude the transitional package)  and isc-dhcp-client Breaks: network-manager (<< whatever-version-is-rebuilt-for-v4)
[18:27] <cjwatson> does that sound reasonable?
[18:28] <cyphermox> yeah
[18:28] <cjwatson> just to avoid having to debug weird bugs due to lack of lease renegotiation
[18:28] <cyphermox> well, the new NM will also need to build-dep on the new dhcp, too
[18:29] <cjwatson> right
[18:29] <cyphermox> do you have isc-dhcp in a bzr branch?
[18:29] <cyphermox> or do you want to upload and test fixing upgrades in parallel?
[18:31] <cjwatson> I don't have it in bzr right now, it was tedious for some reason I forget
[18:31] <cjwatson> you can just copy it from my PPA to the n-m one
[18:31] <cyphermox> but then it would be missing the added Breaks ;)
[18:31] <cjwatson> I can upload a ppa3 for that if you tell me the version number
[18:31] <cyphermox> sure, just a second
[18:35] <cyphermox> if you Breaks: network-manager (<< 0.8.2~rc1) I think it should be good. 0.8.2~rc1 was tagged a few days ago, and I'll upload the latest commit on that git branch
[18:36] <cyphermox> cjwatson, with these changes, network-manager would end up held until dist-upgrade, right?
[18:36] <cjwatson> OK
[18:36] <cjwatson> yes, I believe so
[18:36] <cyphermox> ok
[18:38] <cjwatson> uploaded
[18:40] <cyphermox> cjwatson, thanks
[18:45] <Riddell> how do I tell /usr/lib/pbuilder/pbuilder-satisfydepends not to run autoremove?
[18:47] <kees> chrisccoulson: have you opened an upstream gcc bug yet? I'd say that after doing the -snapshot test and isolating the assembler difference should be more than enough for upstream to poke at it.
[18:53] <chrisccoulson> kees - yeah, i might do that in a bit
[18:53] <chrisccoulson> as long as what i've done makes sense ;)
[18:54] <kees> chrisccoulson: from my perspective, yes, quite. :)
[19:14] <mgunes> mvo, I surmise that update-manager no longer switches to partial upgrade mode every time it needs to install a new package, but offers "New install" items under a "Distribution updates" heading instead. Is this valid for all new packages? Are there any remaining cases for partial upgrades? I haven't found the new behavior documented anywhere.
[19:24] <mvo> mgunes: the only time it will ask for partial is if it needs to remove a package - but that should not happen on stable
[19:26] <mgunes> mvo, is partial still to be expected in the development branch when the archive is inconsistent?
[20:21] <cody-somerville> Riddell, Can you set a contact e-mail address for kubuntu-ppa so that I don't get e-mailed about that team's build failures?
[20:30] <highvoltage> LP really needs to fix that somehow :)
[20:38] <soren> highvoltage: Some of us use that as a feature, actually :)
[20:39] <rangerpb> question about building .debs.  Using dh_make and dpkg-buildpackage to compile and package things up, if I needed to add a user before installation of the package, where would I stick that?  In the rpm spec, it's in %pre
[20:40] <cjwatson> call adduser in a preinst script
[20:40] <cjwatson> normally lives in either debian/preinst or debian/<package>.preinst (the former applies to the first binary package listed in debian/control)
[20:40] <rangerpb> yes, there is a foo/debian/preinst.ex file
[20:41] <rangerpb> do I rename that to just preinst?
[20:41] <rangerpb> And do I have to "hook" it somehow?  because I actually did add it in there, and it didnt work earlier, so I figured I had something messed up
[20:43] <cjwatson> rename it to preinst, yes.
[20:43] <Riddell> cody-somerville: ok
[20:43] <cjwatson> use 'dpkg -I foo.deb' to see if it winds up in your package
[20:43] <cjwatson> unless you have decided to write debian/rules extremely very much by hand, you don't need to hook it
[20:44] <cjwatson> all the .ex files should either be renamed or removed
[20:45] <rangerpb> cjwatson, ah, ok, now I see the difference.  during dh_auto_install of the package, it checks for the user and fails bc it doesn't exist.  the preinst file only goes in once it is build I presume?
[20:45] <cody-somerville> Riddell, ty
[20:45] <rangerpb> so maybe I need to manually add it to complete the build of the package.
[20:45] <cjwatson> rangerpb: you'll need to fix the upstream build system
[20:45] <cjwatson> it needs to not rely on a particular user being present during build - it won't be present e.g. when you upload it to a PPA
[20:46] <cjwatson> (and there's no way that you can add it in such an environment)
[20:46] <rangerpb> Ok, i thought it was goofy to begin with
[21:01] <Wubbbi> When do you (we) start to add realy big changes to ubuntu natty?
[21:05] <BUGabundo> evening
[21:05] <persia> Wubbbi, A couple weeks ago, if they are ready.
[21:06] <Wubbbi> persia: ok sound nice. :)
[21:11] <Wubbbi> Do someone know when the fglrx driver will be updated in Natty. We still have an old version. Can someone maybe maintain it?
[21:11] <ScottK> Wubbbi: #ubuntu-x is a better place for such questions.
[21:11] <Wubbbi> ok
[21:33] <superm1> pitti, oh i didn't realize that's an action I had to do. that all looks correct ot me
[21:42] <pitti> superm1: thanks; was mainly meant as a peer review
[21:42] <pitti> superm1: I set you as approver since you requested the change
[21:42]  * pitti -> back to conf
[22:22] <ari-tczew> could someone sponsor 4 merges for main prepared by MOTUs?
[22:23] <sebner> ari-tczew: just subscribe the queue and wait patiently like we all do ;)
[22:23] <ari-tczew> sebner: saying 'wait patiently' is pretty deprecated.
[22:24] <sebner> ari-tczew: well sure, but in the long run you risk to have an "annoying" attitude
[22:24] <micahg> ari-tczew: no, it's still the normal process unless it's needed quickly
[22:26] <persia> ari-tczew, Really, wait patiently is *not* deprecated.  Showing excessive failure to wait patiently is very much not preferred.
[22:28] <ari-tczew> I don't care.
[22:28]  * ari-tczew feels stronger that we should clean up sponsors queue.
[22:29] <persia> As someone who has been responsible for administrating sponsoring for the past few years, I agree it's a good thing, but lots of stuff in the queue is just plain wrong (and always will be).
[22:30] <persia> Based on the data bdrung presented during one of the sponsoring sessions at UDS, the main issue is for the small subset of packages in core, which I think most of us agree are dangerous to touch, as they affect so many things.
[22:31] <persia> I'm actually much more in favour of the new initiative (with extra resources thanks to rickspencer3) to treat aged sponsor requests for core in the same way we do patch review (communicating with upstream and debian and generally shepherding stuff), rather than blind uploading.
[22:31] <persia> We'll have a better distribution for doing it right, even if that means less direct sponsoring.
[22:31]  * sebner agrees with persia 
[22:34] <bdrung> ari-tczew: sync and merges are being processed in a timely manner. patiently waiting works there.
[22:35] <geser> cjwatson: you can take bug 669826 (gparted sync) off your TODO list; bdrung took care of it
[22:36] <bdrung> geser: i process sync requests first - to encourage syncing (and because they are easy)
[22:37] <geser> bdrung: thanks, I also asked cjwatson as he's TIL for gparted
[22:37] <bdrung> TIL?
[22:37] <geser> Touched It Last
[22:37] <bdrung> k
[22:38] <geser> he did the last gparted merge
[22:39] <persia> And for all it's nice to have no barriers, TIL before DIF helps preserve continuity of expertise better than most things we've tried.
[23:30] <cjwatson> geser: thanks