[04:20] Good morning [04:21] morning pitti [05:45] good morning [06:40] good morning [06:42] hi === tkamppeter_ is now known as tkamppeter [07:11] precise opened - wonder how many people will switch to it during month [07:14] hrw: 5-6? :) [07:14] including you [07:14] I switched a vm to precise :-) [07:16] dholbach: that's cheating :) [07:16] amitk: ;) [07:25] dholbach, what vm infrastructure do you use/recommend? [07:26] I just use kvm - I used a normal .iso to install it there [07:26] https://wiki.ubuntu.com/UsingDevelopmentReleases has a lot of different options [07:26] dholbach, okay, thanks [07:35] dholbach: Could you sponsor my patch at https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/874028 ? [07:35] Ubuntu bug 874028 in ibus-chewing (Ubuntu) "The preferences window of ibus-chewing crashed after clicking save button." [Undecided,Fix committed] [07:38] FourDollars, I'm a bit busy with other stuff right now - maybe you could ping the patch pilot in the topic of the channel? [07:39] dholbach: I see. Thanks a lot. :) [07:39] no problem [07:40] smoser: ping [07:47] FourDollars, from what I read here https://wiki.ubuntu.com/StableReleaseUpdates , it is better to have the fix already in the development series before requesting an update to the stable one [07:48] a fix for P should probably happen anyway right? [07:49] FourDollars, also the upload now targets a released version, so the changelog should have oneiric-proposed as the series name [07:50] janimo: Thanks you for your correcting. :) [07:50] FourDollars, I just read that doc now, I also need to work on a separate SRU :) [07:51] I think in the first week, fixing relatively straightforward issues directly into -proposed is ok [07:51] it's not like it would actually be tested by anyone in precise [07:51] (assuming you copy-up from oneiric-proposed to precise) [07:52] ibus-chewing that I work on is the same version in precise and oeniric. [07:53] How should I do ? [07:53] Changing oneiric to oneiric-proposed ? Or oneiric to precise? [07:53] upload to proposed as usual, and request that it be copyied to precise when accepted [07:55] I see. Thanks, tumbleweed. [07:57] tumbleweed, I am glad to hear there are some exceptions :) [07:58] * tumbleweed isn't in the SRU team, I just know what I've done in this situation :) [07:59] I have changed bzr repo from oneiric to oneiric-proposed. [07:59] What should I do next? [07:59] What should I do in next step? [08:00] This patch should just be a Stable Fix . [08:02] FourDollars: target oneric-proposed in the changelog, use 1.3.9.2-3ubuntu1.1 as your version, and get a sponsor to upload it. Then add a comment on the bug, asking the SRU team to copy it up when accepting it. === jamespag` is now known as jamespage [08:05] tumbleweed: Should I use 1.3.9.2-3ubuntu1.1 because 1.3.9.2-3ubuntu1 is my upload? [08:05] tumbleweed: I just want to upload second patched version. [08:06] FourDollars: the .1 makes it obvious that it was an SRU. See the security team's verisoning policy linked to from the SRU wiki page [08:07] tumbleweed: I see. Thanks for your explanation. [08:09] I have changed to 1.3.9.2-3ubuntu1.1 . [09:20] mvo, i saw your analysis of the upgrade issue, do you want me to remove the package to confirm its my issue, or wait until you have something to test [09:22] apw: please remove I have the dpkg status file that was enough to reproduce the problem [09:23] mvo, awsome preplanning ... will do and update theb ug [09:23] mvo, i've been seeing people reporting in forums about 11.04->11.10 mythbuntu upgrades pulling in unity-greeter rather than mythbuntu-lightdm-theme. no one has filed a proper "bug" yet for it, but do you think this can be a side effect of calling do-release-upgrade without --mode=desktop? [09:26] superm1: it shouldn't be, the release-upgrader should figure this out automatically, it would be cool to get access to the logs when this happend [09:29] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Precise open for uploads | Ubuntu 11.10 Released! | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: tjaalton, smo [09:30] * cjwatson flushes through an initial batch of mass syncs to precise, up to fonts-vlgothic [09:30] I'll do the next batch after a publisher run has happened [09:31] cjwatson: oh, sync-source.py is working again? [09:31] or do we use an lplib tool now? [09:31] huzzah === doko__ is now known as doko [09:32] Hmm.. precise-changes mailing list doesn't seem to be showing everything. [09:33] WFM [09:33] Daviey: oh, "everything" -- what's missing? [09:33] yeah, not me [09:33] pitti: https://launchpad.net/ubuntu/+source/nova/2011.3-0ubuntu7 [09:33] https://launchpad.net/ubuntu/+source/ajaxterm/0.10-12ubuntu1 [09:33] https://launchpad.net/ubuntu/+source/antlr/2.7.7+dfsg-1 [09:33] https://launchpad.net/ubuntu/+source/libxml-security-java/1.4.5-1 [09:34] Infact, everything i have done.. :) [09:34] right, confirmed [09:34] (including sponsorships.) [09:34] pitti: wgrant fixed sync-source [09:35] pitti: moving to an lplib tool is blocked [09:35] Daviey: #launchpad(-dev) might be better placed to look into this [09:35] Daviey, cjwatson: I poked bigjools about that earlier, but I think he's distracted. [09:36] Daviey: FWIW I think I have been saying that I don't yet advise using syncpackage for sponsorships, and that people should continue to use old-style sync requests for those for now [09:36] I don't know if mailman is stopping them, or LP isn't sending them, or... [09:36] cjwatson / wgrant: ok, thanks [09:37] cjwatson: Yeah, i'm not sponsoring sync's.. (although i did do one that someone had requested shortly before). [09:44] Hello. [09:45] I am the maintainer of the Debian package itstool, which is ahead from the one in Ubuntu. [09:45] So if someone is able to sync, please do so. :-) [09:46] Tanguy: https://wiki.ubuntu.com/SyncRequestProcess [09:46] somebody will need to verify that there are no Ubuntu-local changes lost by a sync [09:46] There are. [09:46] there are changes lost? [09:46] The package currently in Ubuntu was done for Ubuntu only. [09:46] Because at that time itstool was not in Debian. [09:46] I mean substantive changes, not changelog or whatever [09:47] I do not think there are. [09:47] please put this information in a sync request bug [09:47] we don't process syncs by IRC, it would get unwieldy :-) [09:47] definitely appreciate your interest though [09:48] hmm, why is merge-o-matic showing differences relative to unstable [09:48] I told it usto use testing [09:48] tjaalton: ping [09:49] FourDollars: pong [09:49] tjaalton: Could you help https://bugs.launchpad.net/ubuntu/+source/ibus-chewing/+bug/874028 ? [09:49] Ubuntu bug 874028 in ibus-chewing (Ubuntu) "The preferences window of ibus-chewing crashed after clicking save button." [Undecided,Fix committed] [09:50] tjaalton: There is a crash bug existed in oneiric and precise. [09:50] cjwatson: Okay, as long as it is simple, for I have no specific interest in Ubuntu except the will to be nice. :-) [09:50] FourDollars: so upload to both oneiric-proposed and precise? [09:50] tjaalton: Yes, if it is ok. [09:50] FourDollars: sure, setting up chroots first [09:51] Tanguy: otherwise perhaps ask mterry, since he prepared the Ubuntu package [09:52] tjaalton: Are you asking me to set up chroots or you are setting up chroots? [09:52] cjwatson: I think I can assume he will see the sync request. [09:52] did we make syncpackage / requestsync default to testing? [09:52] FourDollars: no, I'm doing that right now, will get to your bug later [09:53] tjaalton: I see. Thanks. [09:53] Laney: not in oneiric at least [09:53] indeed [09:57] Laney: I assumed we'd still want to default to unstable for manually requested syncs (or I would have made the change near the end of oneiric) [09:57] I can see that argument, certainly [09:58] cjwatson: maybe you'll know: I noticed that lp doesn't have a release date for oneiric. Can someone set one? http://paste.ubuntu.com/710708/ (Asked a few times on the weekend, with no response) Should this be on one of the release checklists? [10:00] can't, requires an LP admin [10:00] ok, I'll poke #launchpad, thanks [10:00] this went wrong in natty too, but IMO it shouldn't be checklisted, LP should be fixed to set it automatically when the distroseries goes to CURRENT [10:01] right, a bug then :) [10:01] hmm, not bothered either way. At least for haskell that is true (because migrations are pretty awful there). [10:07] filed bug 876345 [10:07] Launchpad bug 876345 in Launchpad itself "distro series releasedate not automatically set" [Undecided,New] https://launchpad.net/bugs/876345 [10:07] ah, bzr update in mom's deployed branch failed [10:07] * cjwatson runs bzr upgrade to fix that [10:09] with any luck it won't run out of disk [10:10] I've also fixed rmadison to not have stale data for precise (its mirror wasn't using --delete so it had stale uncompressed Packages/Sources lying around) [10:13] tumbleweed: for the last lts where we also synced from testing, requestsync defaulted to testing. IMHO it should do it now too. It might not be important till DIF (when the tools are used seldomly) but more important after DIF. If someone sync from unstable it should be because they passed an option and not because they missed to tell it should sync from testing. [10:16] hrm, u-d-t SRU time then [10:16] cjwatson, is -Werror=format-security really that a good idea? [10:18] in general I appreciate these warnings, as they are often real bugs [10:18] doko: I think it is [10:18] did you find a case where it isn't? [10:18] it has a pretty good hit rate [10:18] sure, there's the odd FP, but also lots of cases where people assume that translators never get format strings wrong [10:18] (or are never malicious ...) [10:19] well, what it the use for something like printf("foo\n"); ? [10:19] just watching the ftbfs list grow because of this [10:19] if that generates an error, that indeed looks wrong [10:20] that shouldn't fail -Werror=format-security [10:20] it is certainly not documented to fail it [10:20] if gcc is failing that, that's a gcc bug [10:21] it doesn't here, at least not in precise [10:21] printf("foo\n"); [10:21] -> no error [10:21] printf(f); [10:21] -> error, as it should [10:22] sorry, s/not in precise/not in oneiric/ [10:22] yes, it was the latter. however if we didn't have this until now, why for the lts? [10:23] we had it in oneiric, no? [10:23] no [10:23] this comes with the dpkg merge [10:24] oh, do you mean that this is a dpkg change? I wondered why you were asking me [10:24] context helps! [10:24] sorry =) [10:24] if you want to back that out of dpkg for the LTS, feel free [10:24] is there a way that we could keep that for main packages only? [10:24] let's see how many ftbfs we'll get with this [10:24] it was a 445000-line change, I didn't look at all of it :-) [10:25] pitti: if you want to mess with dpkg-dev, maybe. [10:25] yeah, it would be nice to see if it's feasible to keep that; given that the change is in Debian we should not be getting new failures added from here on, only old ones [10:26] I wouldn't want to hack dpkg to know about different components [10:26] doko: too fiddly within dpkg-dev IMHO [10:26] it would be horribly confusing for local builds [10:26] I meant, could the buildds export a different CFLAGS depending on the components [10:27] but right, local reproducability [10:27] ok, ignore me then [10:45] I don't suppose anyone has written a tool to unpack all the source for the base system? I'm trying to find out what packages use the automatic codec installation, and grepping for the header seems like the most straightforward approach. [10:45] yay @ component-mismatches explosion [10:47] ev: I have a little "for-srcarchive" script on lillypilly:~pitti/bin/ which you give an archive root (/srv/archive.ubuntu.com/ubuntu), a sources path (dists/precise/main/source/Sources.gz), and a command to run there (like grep ...) [10:48] ev: it outputs ==== pkgname === and then the output from the command [10:49] it runs a couple of hours for universe, though [10:54] ev: it's likely going to be mostly totem, rhythmbox, banshee [10:54] dunno about others [10:55] pitti: awesome! [10:55] seb128: indeed, thanks [11:22] hi ev are you here ? [11:25] grmlmgmr (sorry) [11:31] slangasek: Hey there, I see "syncpackage: Source package u-boot is blacklisted." when using syncpackage on u-boot; I can't find it in the old http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt and I can't find a link to an explanation at https://launchpad.net/ubuntu/+source/u-boot but would you remove it from the blacklist? I can't see a reason it should be blacklisted, we need it to provide mkimage in Ubuntu [11:31] (and it's in already in Ubuntu since some cycles) [11:32] lool: it's only blacklisted for a particular pair of versions [11:33] lool: that's just syncpackage/LP being obscure about the fact that it has Ubuntu changes. Use -f. [11:33] LP does that automatically, and in a buggy way, this isn't the only package with that problem [11:33] cjwatson: I checked on another package and didn't get this warning, maybe I picked my sample wrong though [11:33] lool: it's not blacklisted, anyway. [11:33] lool: use -f. [11:33] lool: bug 841372 [11:33] Launchpad bug 841372 in Launchpad itself "Incorrect auto-blacklisting in DSD?" [Low,Triaged] https://launchpad.net/bugs/841372 [11:33] cjwatson: Yup, I actually sync-ed with with -f already [11:34] tumbleweed: thanks [11:35] tumbleweed: where did you find the list of blacklisted versions? [11:35] you can do an api query [11:44] slangasek: (never mind, apparently a known LP bug) === MacSlow is now known as MacSlow|lunch [12:24] <\sh> hmmm...oneiric and an asus pro 61S laptop is a total nogo === MacSlow|lunch is now known as MacSlow === smb` is now known as smb === dendro-afk is now known as dendrobates [15:23] hm, I need to merge gnutls26 pronto apparently [15:24] Looks like mono-xsp-base was deleted from Oneiric - anyone know if it was put in another repo? [15:24] Alternatively, is there a better place to ask? [15:25] now that size of build queue is what I like to see [15:25] Laney: and I haven't even completed the mass sync ... [15:25] are you doing new packages at the same time? [15:26] * [9e2a65a] Move XSP4 features into a new mono-xsp4-base package, and [15:26] rename mono-xsp-base to dh-xsp since it only contains dh_installxsp. [15:26] Rantpaste: ^- [15:26] yeah, 1.1 has gone away [15:26] we have xsp2 and xsp4 now [15:26] Cool [15:26] Laney: a few at a time, yes [15:26] so my iFolder package needs updating :) [15:27] didn't that have license problems or something? [15:27] Laney: not terribly consistently, so shout if anything's urgent [15:28] can't think of anything major, there was some mono stuff that people wanted backporting but a) I can't remember what it was and b) it's not so urgent [15:29] if you could do haskell-* from unstable at some point though [15:31] I did :-) [15:31] oh, well, from testing [15:31] for stuff from unstable I'd prefer to have sync request bugs (or you can syncpackage them) [15:32] waiting for it to migrate is a pain [15:32] I'll sort something out at some point then [15:32] right, I don't mind people explicitly syncing stuff from unstable when they know what they're doing, I just don't want rationale/requestor hidden behind the autosync machinery [15:33] fair [15:34] maybe the clever new hinters will make migration behaviour nicer at some point [15:35] oh, BTW, I added http://people.canonical.com/~ubuntu-archive/transitions/libjpeg.html [15:37] doko, cjwatson: yeah, the Werror=format-security caused about 120 ftbfses in the debian archive, iirc. most of them have been tagged in the bts and patches and being made. I think it's worth it too, but I did intentionally only turn it one in dpkg-buildflags so that it would slowly make it's way into the builds instead of putting it in the compiler like the others. [15:38] it has a fair bit of FP, but catches enough real bugs to make it worthwhile [15:41] pitti, hi [15:41] wait, I forgot, iulian wants to help look after Haskell this cycle :-) [15:42] pitti, can you have a look at https://launchpadlibrarian.net/83022758/buildlog_ubuntu-precise-amd64.ghostscript_9.04%7Edfsg-0ubuntu12_FAILEDTOBUILD.txt.gz, seems that the buildds is not able to install CUPS on precise. [15:42] Laney: any haskell transitions this time? [15:42] just the usual [15:43] probably get a new ghc with the new platform at some point [15:44] oh argh, gnutls26 indirectly self-build-depends and is currently uninstallable [15:44] tkamppeter: this could be due to the gnutls merge cjwatson is working on [15:44] maybe it will build cleanly in an oneiric PPA? [15:44] tkamppeter: yeah, ignore it for now [15:44] pitti, problem is on all supported archs. [15:45] tkamppeter: yes I know [15:46] cjwatson, it builds cleanly in an Oneiric PPA, as the main change (liblcms1 -> liblcm2) I have already made available via PPA, the other differences to my PPA version are small patches. [15:47] cjwatson, geser, it will be rebuilt after the buildds is fixed? [15:47] tkamppeter: yes, please leave me alone for now to work on it [15:48] tkamppeter: yes if someone gives it back after the buildds got fixed === dendrobates is now known as dendro-afk [15:49] I will take care of it [15:54] bdrung, do you look after vlc? [16:03] chrisccoulson: you are thinking about 1.1.12 for oneiric? [16:03] bdrung, no, i just got pinged by someone from mozilla about bug 876625 ;) [16:03] Launchpad bug 876625 in vlc (Ubuntu Oneiric) "VLC plugin is making Firefox crash" [Critical,Triaged] https://launchpad.net/bugs/876625 [16:05] chrisccoulson: oh, haven't seen this bug yet. i am on amd64 [16:05] yeah, me too [16:05] chrisccoulson: i have no time this week to look at it deeper [16:06] chrisccoulson: can we get vlc 1.1.12-2~oneiric1~ppa1 from https://launchpad.net/~bdrung/+archive/ppa tested against this bug? [16:06] bdrung, if we can find someone to reproduce it :) === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [16:14] mvo, ok, i'be been trying to get people to file bugs, but nothing yet. with how prevalent it is, hopefully someone will [16:16] slangasek: Hey, are you able to chime into bug 862129, would like to try and get this moving. Dupes are arriving quickly [16:16] Launchpad bug 862129 in samba (Ubuntu Precise) "samba postrm depends on packages not guaranteed to be configured" [High,Triaged] https://launchpad.net/bugs/862129 [16:16] superm1: thanks, once there is a useful log, please let me know I will jump onto it [16:16] ok === firewave is now known as FireWaveJob [16:40] cjwatson: is there some special trick one must do to enable dh_apport or is dh7 supposed to call it automatically on ubuntu? [16:40] dh --with apport [16:40] and build-depend on dh-apport [16:41] (sorry, to be clearer, it's typically 'dh $@ --with apport' - I should mention that since the command-line ordering is counterintuitive) [16:42] cjwatson: ok. could it be a good idea to implement it by standard, witout the need to explicitely --enable-it or is there any particular reason for not doing it? [16:43] it's an Ubuntu-specific thing and I don't think we should change the default behaviour of debhelper [16:43] besides, --with is a common way to extend dh's behaviour [16:43] see e.g. --with python2 [16:43] yes, it's ubuntu-specific, but it would seem to make sense to auto-install any *.apport found whenever building for ubuntu. [16:43] stgraber: Is merging fetchmail on your plan? [16:44] to do that it would have to be integrated into debhelper proper [16:44] which is not currently on my list of things to do [16:45] yes, it would, and it would make sense to include this as a standard part of the debhelper diff for ubuntu. [16:45] ah. oh well. [16:45] that's a guaranteed way to ensure it never gets into Debian [16:45] cjwatson, is dh-apport doing anything out of installing the hooks? [16:45] so I'm not going to slam it into Ubuntu's debhelper, no [16:45] seb128: no [16:45] cjwatson, I usually just list those in the .install, that seems smaller diff than adding a build-depends and a rules change but I might be overlooking something [16:45] ok, thanks [16:46] I prefer having a dh_ command for it. you are welcome not to use it. [16:46] I really don't care :) [16:46] yeah, I just wanted to check if I missed a good reason to use it ;-) [16:46] we welcome the command, not the extra build-deps. [16:46] but ok, fair enough :) [16:46] * cjwatson shrugs [16:47] don't count me in this "we", I'm fine with the build-depends being there ;-) [16:47] fair enough :) [16:47] it seems kind of bizarre to me to have an extension mechanism and then object to using it :-) [16:48] it seems even more bizare to not include it by standard in the ubuntu diff for debhelper. :) [16:49] politics, to some extent. [16:52] Daviey: not really, am I touched-it-last on it? [16:52] stgraber: looks like it :) [16:53] Daviey: well, if you want to do it, feel free :) otherwise I'll look at all of these where I'm touched-it-last either this week or next [16:53] stgraber: Are you attached to the delta, https://launchpad.net/ubuntu/+source/fetchmail/6.3.19-1ubuntu1 ? [16:54] Daviey: what chiming are you looking for on bug #862129? I've commented on the historical reasoning for the package being the way it is, I don't really have input beyond that [16:54] Launchpad bug 862129 in samba (Ubuntu Precise) "samba postrm depends on packages not guaranteed to be configured" [High,Triaged] https://launchpad.net/bugs/862129 [16:55] Daviey: nope. I never used fetchmail as a daemon :) I think I'm touched-it-last on this one because I took all of Artur Rona's merges last cycle, so feel free to sync from Debian if you're not attached to that delta either [16:55] stgraber: It doesn't look worthwhile to carry IMO, can always re-introduce it. [16:55] thanks [16:56] thanks for reducing my list of merges ;) [16:57] (fwiw, i don't think the touched-it-last is the best way of allocating work.. but *shrug*) [16:58] it's not a way to allocate work [16:58] it's a way to avoid duplicating work [16:58] people are welcome to hand things over [16:59] "I'd like to do this merge; are you working on it?" is entirely reasonable [16:59] stgraber: I grabbed a few of those as well :), unless you're referring to main only [17:00] micahg: I only looked at main, I'm sure he had a lot more in universe [17:00] pitti: would this be a good week to get Firefox 7/final langpack run for maverick going or would you like to wait until after UDS? [17:00] stgraber: ah, yeah === beuno is now known as beuno-lunch [17:39] tjaalton: still piloting? [17:42] hmm the new umask in oneiric seems to be affecting the buildds. [17:43] hyperair: how? some packages might be buggy by assuming a umask instead of setting the one they expect [17:43] geser: no, it's a dh_thing [17:43] geser: what's that dh_ thing that optimizes pngs? [17:43] pkgbinarymangler [17:43] -rw-rw-r-- root/root /usr/share/icons/hicolor/48x48/apps/gnome-mplayer.png [17:43] see that? [17:44] i suspect it's the same for all png files of packages using dh_blah that are built after the umask change [17:45] file a bug against pkgbinarymangler and pitti will look at it [17:47] I think that pkgbinarymangler bugs has been fixed already [17:47] hmm really? [17:47] i had issues with sbuild very recently [17:47] something like yesterday or the day before [17:48] anyone want to sponsor a really simple fix for a main package for me? [17:48] bug #817792 [17:48] Launchpad bug 817792 in pkgbinarymangler (Ubuntu) "pkgstripfiles doesn't preserve permissions of png files" [High,Fix released] https://launchpad.net/bugs/817792 [17:48] maco: sure [17:48] stgraber: thank you! https://code.launchpad.net/~maco.m/ubuntu/oneiric/nvidia-settings/fix-missing-dependencies-for-kubuntu/+merge/79588 [17:49] debfx: oh nice. [17:50] maco: was that uploaded to Precise already? [17:50] debfx: would it be wise to rebuild the affected packages? [17:51] a quick check of my /usr/share/icons reveals upwards of 600 affected icons. [17:51] stgraber: no. i thought (from -devel ml) that syncs were busted on precise... are there packages there to futz with now? [17:51] I don't think so as long as the files are owned by root:root [17:52] if so i guess i can make a merge proposal for that too, but itll be the exact same diff :P [17:52] maco: I think syncs have been fixed today, though if that's in Debian it'll get synced automatically and fixed then. I just want to make sure we don't get a regression on Precise [17:52] debfx: true that. i guess we can just leave it then [17:52] maco: does 280.13-1 in Debian contain that fix? [17:52] some mass-syncs from testing were done today [17:55] maco: uploaded to oneiric-proposed [17:56] im looking. i dont see anything in debian's changelog about it, but downloading to check the control file anyway [17:56] maco: and also uploaded to precise so whoever ends up doing the merge won't iss it [17:56] *miss [17:56] debian's missing it too [17:56] thanks [17:57] guess i should talk to the debian maintainer [17:57] yep, would be good to have that fixed in Debian [18:00] maco: oops, that didn't quite work because of the package using a control.in... I should have seen that [18:01] maco: I'll upload a new one to precise and -proposed [18:01] crap :( [18:02] hmm.... [18:02] oh how odd [18:02] debian's DOESNT use a control.in [18:02] but ours does === zyga is now known as zyga-afk [18:10] SpamapS: Hi! There's currently two nvidia-settings package with the same version number in the proposed queue for Oneiric. Can you reject the first one (the one where the only change is debian/changelog)? [18:11] stgraber: ACK, will take a look shortly as I'm about to start doing SRU reviews [18:12] SpamapS: thanks === beuno-lunch is now known as beuno [18:13] stgraber: thats confusing [18:14] because lp's diff preview on the merge request shows changes in control [18:15] or are control & control.in both in the source package even though control is generate? [18:15] yeah, it's one of these cases where the branch looks good but running debuild drops the change... except that "bzr bd" runs outside of the branch so you really need to debdiff the result... [18:16] i think i get why ScottK doesn't use bzr branches [18:16] they're hell with quilt and sometimes hide problems [18:16] both are in the source package with the real control being generated when you run debuild. I guess it would probably be better not to have debian/control in the branch at all as it's generated, that'd avoid the confusion [18:18] stgraber: I try to remember to debdiff the new version against the old before uploading in case something like this happens [18:19] micahg: yeah me too, though this time I forgot and only did it post-upload... [18:19] stgraber: it happens :) [18:19] stgraber: if it's only -proposed, it can be rejected still if it hasn't been accepted yet [18:19] i have a question [18:19] micahg: it needs up taking quite a bit of bandwidth though when you need to: grab the branch, merge, commit, push the change, grab the current source package, diff the two and upload :) [18:20] that answered it [18:20] wanted to know how you debdiff when youre going from a branch [18:20] i guess you could bzr branch, bzr bd, change, bzr bd, debdiff [18:20] maco: grab the old source :) pull-lp-source works for that [18:21] micahg: yeah, I asked SpamapS to reject and I uploaded a clean one with the same version number. Though I had to do two uploads to Precise as I initially pushed to both -proposed and precise :) [18:21] maco: yeah, that's assuming you trust the bzr branch ;) I prefer to trust what's in the archive [18:21] at that point i wonder why use bzr then :-/ [18:21] if youre gonna make a debdiff ANYWAY...might as well just submit that [18:22] and then even the anti-bzr sponsors will take it [18:22] maco: exactly why I don't use it :) [18:22] lool: can I take the vim merge of you? [18:22] it's nice to stage changes and get more meta-data on what's been commited [18:24] maco: well, I don't use it for stuff that I don't actively maintain (random universe packages) [18:24] oh right. maintain. i should fix that debian package... [18:24] (not this one. the one im actually listed as an uploader on) [18:26] geser: I've uploaded it already? [18:26] geser: sorry, upload was rejected for some reason, but it's ready [18:26] ok then [18:27] re-uploaded [18:27] it was missing the .orig.tar.gz the first time, I thought I had pushed it again, but apparently not [18:27] geser: but in general, I wouldn't mind you caring for it in the future as you seem to be used to this diff ;-) [18:28] sure, therefore I asked as I did the last merge but you did the last upload [18:29] ack; thanks for the offer [18:31] I need to shorten the diff to the changelog on the next merge as it is way longer than the actual changes [18:33] quilt doesn't support binary diffs, right? [18:37] jbicha: they can be included directly in the .debian.tar.gz with dpkg-source's included-binaries option [18:39] tumbleweed: I'm trying to add a missing binary to a ubuntu-desktop branch, how would that work? [18:40] jbicha: is the binary supposed to be in the source package? [18:40] geser: Eh [18:40] geser: If you're tempted to look into it, it FTBFSed due to other packages being uninstallable [18:40] probably mass sync issues [18:41] I'm trying to backport this commit which missed 3.2.1 by a few hours http://git.gnome.org/browse/aisleriot/commit/?h=gnome-3-2&id=b9a1f676657a729f1a3bfd0952879c25c9c74f76 [18:41] oooh oggs [18:42] yeah i think youre gonna have to go with what tumbleweed said [18:42] jbicha: with svn, one just included them in the tree, outside the ubuntu dir. Never done it with bzr. /me looks [18:43] I think it's a little more complicated since we generally only have debian/ in our packaging branches? [18:43] no I'm also talking about merge mode in svn [18:43] oh ok [18:43] lool: the problem is the pending libgnutls merge but it's being worked on [18:44] jbicha: I think with source format 3, you can throw it in the debian dir and move it into place in .install [18:45] Hey kees, can you point me where i can find information about the AppArmor mediation of DBus communications? [18:45] i saw the blueprint, its says "Beta Available". Where i can find out this code? [18:45] jdstrand: ^ [18:46] zimmerle: jjohansen might be able to help you [18:46]