[01:29] <soren>         tree
[01:29] <soren>         tree
[01:29] <soren> Gah..
[01:29] <soren> blame unity :)
[01:41] <highvoltage> hey Pendulum
[01:42] <Pendulum> hi highvoltage
[01:42] <highvoltage> how are things?
[01:43] <Pendulum> not bad. I'm getting excited about all the accessibility stuff we're planning for next cycle :-)
[01:44] <highvoltage> great
[04:59] <achiang> is it kosher to issue a command as 'sudo' in a maintainer script? goal is to run gconftool as another user
[05:50] <jdong> achiang: you should probably use su for that
[07:12] <dholbach> good morning
[07:48] <didrocks> good morning
[07:49] <pitti> Good morning
[08:14] <sabdfl> morning everyone, happy release day :-)
[08:15] <maco> uh oh. if you're awake, it must be way past bedtime
[08:15] <Tm_T> morning, and happy thursday (:
[08:16] <pitti> hey sabdfl, same to you!
[08:16] <dArKd3ViL> :)
[08:16] <dArKd3ViL> its been morning for me since past 24 hrs now :P
[08:16] <dArKd3ViL> anziety attacks you knoe
[08:20] <hrw> morning
[08:39] <cdbs> pitti: You're running Oneiric?
[08:40] <cdbs> pitti: As seen on bug #772185
[08:43] <azm> hi, how do I compile source for windows with gcc-mingw32 please ?
[08:44] <azm> I need to issue something like this
[08:45] <azm> gcc.exe -shared -o func.dll -Wl,--out-implib=libessfunc.a -Wl,--image-base=0x6350000 essfunc.o
[08:46] <pitti> cdbs: am I? I have doko's oneiric-staging toolchain PPA enabled
[08:46] <pitti> but otherwise natty
[08:46] <cdbs> pitti: ah, explains then :) I was surprised to see an Oneiric tag
[08:46] <pitti> $ lsb_release -sc
[08:46] <pitti> oneiric
[08:46] <pitti> oh, wow
[08:46] <cdbs> and DistroRelease: 11.10
[08:46] <cdbs> :D
[08:46] <pitti> apparently I'm on the bleeding edge!
[08:46] <cdbs> pitti: :)
[08:47] <SpamapS> pitti: good morning! I've left out reviewing phonon-backend-gstreamer and libofx from the natty-proposed queue.. both seem rather different..
[08:47] <pitti> SpamapS: thanks for catching up with the rest!
[08:47] <SpamapS> pitti: there have been so many.. :-P
[08:48] <pitti> SpamapS: must be release time or so
[08:48] <pitti> SpamapS: I'll keep the queue down over the day
[08:48] <SpamapS> pitti: :)  I also uploaded my own, mdadm .. which seems fairly straight forward
[08:48] <pitti> SpamapS: it's such an enormous help to have two people doing this, thanks!
[08:48] <pitti> SpamapS: yep
[08:49] <cdbs> I thought earlier that there were other SRU team members as well, apart from SpamapS and pitti
[08:50] <pitti> cdbs: formally yes, but they process stuff only on request, not regularly
[08:50] <cdbs> hmm
[08:51] <pitti> SpamapS: oh, btw: for the "right after release" case, we usually copy natty-proposed to oneiric once it's verified
[08:51] <pitti> SpamapS: which settles the case of "fix in dev release first" while it is not actually open yet
[08:53] <SpamapS> pitti: I have been opening tasks in Oneiric just in case.. but that makes perfect sense.
[08:53] <pitti> having the tasks is fine, of course
[08:53] <pitti> SpamapS: just to let you know about this special case, there's no blocking of SRUs here
[08:53] <SpamapS> will the copying trigger the launchpad bug updater?
[08:54] <pitti> SpamapS: in a weird way, but yes
[08:55] <pitti> copying natty-proposed to oneiric will close the natty task
[08:55] <pitti> so after that we need to manually close oneiric
[08:55] <pitti> SpamapS: you can't do this yet, but our sru-release script does the copying to the dev release automatically if you set FORWARD=1, and the versions in natty and oneiric match
[08:56] <SpamapS> pitti: sweeeeet
[08:56] <SpamapS> pitti: so all these SRU's that are verification-done .. they still need to bake for 7 days? doesn't that make them , like, 4 - 6 day SRU's ?
[08:57] <pitti> SpamapS: correct
[08:57] <pitti> well, except in some justified high-urgency/safe cases
[08:57] <pitti> like tzdata or this dell-recovery thing
[08:57] <SpamapS> right ok
[08:57] <pitti> but as a minimum they need the standard SRU verification
[08:57] <pitti> SpamapS: we can probably release them next Monday, a little less than 7 days
[08:58] <pitti> SpamapS: but I'm not very comfortable releasing many updates on a Friday
[08:58] <mdke> ah, we can do SRUs already? Awesome
[08:59] <pitti> mdke: yes, for a while; in fact you can technically upload to oneiric-proposed already :)
[08:59] <pitti> (at least as soon as uploading to oneiric itself works)
[08:59] <pitti> they just won't be processed
[08:59] <mdke> pitti: ok, will try and get new ubuntu-docs and gnome-user-docs packages ready over the weekend
[08:59] <pitti> mdke: nice, thanks
[09:00] <mdke> diffs won't be small though i'm afraid, we have made a lot of progress
[09:12] <pitti> SpamapS: btw, I just noticed on https://edge.launchpad.net/+apidoc/1.0.html that we apparently can use launchpadlib for copying packages, so we could rewrite sru-release in terms of launchpadlib and won't need shell access
[09:13] <cjwatson> pitti: s/edge\.//
[09:13] <pitti> ah, firefox history never forgets anything..
[09:14] <SpamapS> pitti: Cool!
[09:15] <SpamapS> pitti: thats fun, so when I've gotten my training, I can either wait for shell access or hack the script. Options are nice to have.
[09:17] <pitti> SpamapS: I'll play around with that the next time an SRU is ready to be copied (or we need to copy a kernel from the PPA to -proposed)
[09:17] <pitti> but it looks straightforward
[09:17] <seb128> slangasek, could you check on bug #771109
[09:18] <seb128> it's a multiarch fallout
[09:18] <SpamapS> pitti: lplib is really nice to use. It was a snap getting it to check for existing versions in -proposed that don't yet exist in updates.
[09:18] <pitti> oh, cool!
[09:18] <pitti> MP! MP! MP!
[09:18] <SpamapS> Well I was going to wait.. but..ok just for you. :)
[09:20] <pitti> SpamapS: I was mostly kidding
[09:20] <pitti> but actually this is especially useful in these times when we get tons of SRUs every day, and uploaders usually don't check for a previous version in -proposed and build with -v
[09:20] <SpamapS> pitti: nah, I've been using it all day. :)
[09:20] <SpamapS> its ready
[09:22] <SpamapS> If there was one thing I'd improve it might be to put the WARNING at the top of the diff
[09:22] <SpamapS> pitti: https://code.launchpad.net/~clint-fewbar/ubuntu-archive-tools/queuediff-check-for-proposed/+merge/59330
[09:23] <SpamapS> tho for now I've just trained myself to 'G' to the bottom just in case
[09:25] <pitti> SpamapS: I'd also print it to stderr in addition, so that you can see it where it also prints the sru-accept command
[09:25] <SpamapS> good idea...
[09:25] <pitti> I'll do that in the merge
[09:25] <SpamapS> cool
[09:25]  * SpamapS is surprisingly untired tonight. :-P
[09:26] <SpamapS> despite eating almost no carbs today and doing a 1 hr karate class. :P
[09:29] <pitti> SpamapS: merged with this change, thansk!
[10:15] <tkamppeter> seb128, mpt, pitti, is it possible to block a UDS session onto Wed-Fri? Tim Waugh is not able to attend remotely on Mon and Tue.
[10:16] <mpt> tkamppeter, I don't know, sorry. jcastro might know.
[10:16] <tkamppeter> jcastro ^^^
[10:17] <seb128> should be possible to shuffle the shedule to accomodate that yes
[10:17] <seb128> check with pitti or jasoncwarner
[10:26] <pitti> tkamppeter: yes, should be possible; is it a blueprint or a roundtable?
[10:26] <pitti> tkamppeter: if tim registers himself as attending from Wed-Fri, and is marked as "participation essential" in the blueprint, the scheduling will take care of it
[10:38] <tkamppeter> pitti, then I will tell Tim to do so. It is a Blueprint: https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-system-config-printer-vs-gnome-3-control-center
[10:46] <pitti> tkamppeter: yes
[10:47] <pitti> tkamppeter: subscribe tim again with "participation essential"
[10:52] <jubei> guys sorry this isn't directly related to ubuntu development. I'm using cmake to build a project and I'm wondering how I can instruct cmake to link certain libs with the executable
[10:54] <tkamppeter> pitti, I have set up everything for Tim now.
[12:06] <highvoltage> yay I see ubuntu is license-free again! no more licensing problems! (under business heading on http://www.ubuntu.com/)
[12:12] <Chipzz> highvoltage: #debian-devel would like to have a word with you :P
[12:19] <highvoltage> Chipzz: how so?
[12:20] <Chipzz> highvoltage: you missed the font license discussion Monday?
[12:25] <highvoltage> Chipzz: ah right :)
[12:25] <highvoltage> Chipzz: well there's another problem solved then!
[12:36] <stgraber> congrats everyone!
[12:36] <Laney> \o
[12:37] <chrisccoulson> w00t
[12:37] <Laney> is oneiric open yet?!?!
[12:37] <Laney> ;-)
[12:39] <directhex> Laney, quick, begin the 2.10 transition!
[12:39] <cjwatson> Laney: later today with any luck :)
[12:39] <cjwatson> (modulo toolchain timings)
[12:39] <cjwatson> champagne first ...
[12:39] <directhex> (no really, julian's already done a lot of the hard work, bless his little cotton socks)
[12:39] <Laney> what a darling
[12:39] <Laney> I'll have some archive fun with the GHC 7 transition
[12:40] <directhex> Laney, boo haskell!
[12:43] <jcastro> \o/
[12:43] <jcastro> now we can relax!
[12:43] <ogra> haha
[12:43] <ogra> now the bugs will come in :P
[12:45] <Chipzz> grats everyone!
[12:48] <paultag> doko_: I (think) I have a fix for one of (what I'm sure was an automated bug) in my PPA. When you get a momement, would you re-try bug #771017 (so I can sleep at night knowing fluxbox is OK for o-series)?
[12:55] <konaya> Where does one report an error on the ubuntu.com page itself?
[12:56] <konaya> Here?
[12:56] <Laney> launchpad.net/ubuntu-website
[12:57] <konaya> Laney, thank you.
[13:09] <konaya> There we go. Bug report submitted.
[13:51] <Sweetshark> whats the right way to become a member of https://launchpad.net/~ubuntumembers? "Contact the teams owner" leads to a webform that sends mail to sabdfl, which is kind of intimidating. ;)
[13:51] <ogra_> lol
[13:51] <sabdfl> i get quite a few of those, yes :-)
[13:51] <paultag> Sweetshark: you must apply for membership via one of the RMB
[13:51] <ogra_> Sweetshark, there are wikipages that explain the membership process
[13:51] <Sweetshark> argh, there is a link right on that page.
[13:52] <paultag> Sweetshark: no need to harass sabdfl [over email]
[13:52] <sabdfl> maybe the contact addy for u-members should go to the RMB's? it's low-traffic
[13:52] <ogra_> depends ... if you send the right bribe you might get the bdfl speed process ;)
[13:52] <paultag> sabdfl: not a bad idea. is there a common ML for all the RMBs?
[13:53] <sabdfl> not sure
[13:53] <sabdfl> i don't mind staying the contact point, but also happy to hand it on
[13:53] <ogra_> there is at least one per board iirc
[13:53] <maco> theres a common list for rmbs + cc + dmb iirc
[13:53] <paultag> maco: I love dave matthews
[13:53] <paultag> maco: also, good morning
[13:53] <maco> huh?
[13:54] <paultag> maco: dmb == dave matthews band (to some of us)
[13:54] <maco> cyphermox: i see your lp team list changed today :)
[13:54] <cyphermox> maco, oh, cool, thanks for pointing it out... and doing the change :)
[13:54] <Sweetshark> sabdfl: given your avatar on launchpad, I still feel like I woke up a sleeping dragon ;)
[13:54] <Sweetshark> thanks guys!
[13:54] <maco> cyphermox: i didnt make the change, just saw the email
[13:55] <cyphermox> ok
[13:58] <Laney> Sweetshark: that page says "Fro more details about ... how to become one, please visit <SOME URL>"
[14:03] <Sweetshark> Laney: right, I already followed the links "Membership"->"DeveloperMembershipBoard"->"DeveloperMembershipBoard/ApplicationProcess"->"UbuntuDevelopment/DeveloperApplicationTemplate"
[14:03] <Laney> excellent!
[15:41] <evfool> sorry for asking this on ubuntu-devel, I can't find the info on the canonical site: does anyone know how to contact someone from the canonical shop?
[16:08] <slangasek> seb128: bug #771109> done
[16:08] <seb128> slangasek, hi, thanks
[16:09] <seb128> I guess doko rebuilt has been running for a while
[16:09] <seb128> it probably started before your fixed version
[16:12] <jibel> Sweetshark, hi, there's a missing transition to libreoffice-dmaths when upgrading to Natty, bug 772387
[16:18] <seb128> cjwatson, pitti: did any of you ever discussed with debian about adding the avahi udeb we have in ubuntu to debian?
[16:19] <seb128> (I'm asking you because you respectively added those and did the recent avahi merge)
[16:19] <pitti> seb128: if I did, it's been a while, and I probably would have submitted it as a bug report
[16:19] <seb128> there is no bug about it that I can see
[16:20] <abhinav-> pitti: I think we can add screenshot taking feature/option in apport now https://bugs.launchpad.net/apport/+bug/772336
[16:21] <abhinav-> I have attached a prototype in the comments
[16:31] <cjwatson> seb128: I don't think I did, sorry
[16:37] <seb128> cjwatson, pitti: does one of you want to do send it or should I just add it to the desktop team "to forward" list (which is fine)?
[16:38] <pitti> seb128: "want" is too much (not my patch), but I'm fine with merging avahi and sending patches
[16:39] <seb128> pitti, ok, feel free to claim it then, thanks ;-)
[16:40] <pitti> https://merges.ubuntu.com/main.html is not yet up to date, is it?
[16:40] <paultag> doko: ping, if you're around
[16:40] <pitti> seb128: opened a tab for it
[16:40] <doko> ?
[16:41] <seb128> pitti, thanks
[16:41] <paultag> doko: I have a fix for the ftbfs with fluxbox, with o-series gcc. I'd like to test it, but I can't upload to natty. Could you pick off the source package and run it through again?
[16:41] <paultag> erm, not natty
[16:42] <doko> paultag: you could test it in a local chroot, or in a PPA, adding a PPA dependency to the mentioned toolchain ppa
[16:43] <paultag> doko: works in a local chroot, I'll see about tweeking my PPA. Thanks :)
[16:46] <cjwatson> pitti: it should be shortly, at least; I did update it for oneiric
[16:47] <pitti> ah, thnaks
[16:54] <Sweetshark> jibel: thanks
[17:16] <Sweetshark> pitti: we inherited bug 772387 from debian, how should we handle it?
[17:18] <Sweetshark> I'd think _rene_ would say it "works as intended".
[17:21] <pitti> Sweetshark: could we upload an SRU which just drops the Depends:? i. e. that it becomes an empty transitional dummy package?
[17:26] <Sweetshark> pitti: yes, we could. But I should then scan for all those cases comparing LO/OOo. I am not sure if all functionality from these packages has been moved into to main libreoffice packages. If not, it might be that people silently loose functionality on update (Not that explicitly uninstalling to be able to upgrade is that much better).
[17:27] <pitti> Sweetshark: right now they lose the functionality either way
[17:28] <pitti> but breaking upgrades is worse
[17:29] <SpamapS> pitti: I need some guidance on bug 771841
[17:30] <pitti> SpamapS: that's a tricky one indeed; I'd rather see a less intrusive patch TBH, as it's not obvious that it doesn't cause regressions in the background setting code for gnome 2.32
[17:30] <pitti> if that has been tested thoroughly, I'd be ok with it
[17:31] <pitti> we often update to new microreleases for GNOME packages, but shotwell doesn't seem to follow their release cycle, so we should be more careful there
[17:32] <seb128> pitti, SpamapS: usually the yorba guys are solid upstream and have high quality standards
[17:32] <seb128> not arguing either way on what to do but just pointint it
[17:32] <seb128> pitti, SpamapS: if they say they tested it they probably did, it's easy to get that checked in proposed as well
[17:34] <SpamapS> Ok it actually sounds like it should be safe....
[17:34] <seb128> well check with mterry maybe if he testedit
[17:34] <SpamapS> maybe accept into proposed, but require some detailed QA verification?
[17:35] <seb128> sounds like a plan to me yes
[17:35] <pitti> agreed
[17:35] <seb128> we should make sure the background thing is tested during the week in proposed
[17:35] <seb128> SpamapS, pitti: or wait
[17:36] <SpamapS> Definitely
[17:36] <seb128> SpamapS, don't accept it if you didn't
[17:36] <pitti> SpamapS: btw, gnome 3 isn't completely irrelevant for natty, we have a PPA for it
[17:36] <seb128> I will ask an extra question on the bug
[17:37] <SpamapS> pitti: agreed, Its just not "supported" like Unity and Gnome 2
[17:38] <SpamapS> so we just need to make sure those work first is all.
[17:38] <seb128> the change is buggy I think
[17:38] <SpamapS> seb128: eh?
[17:39] <SpamapS> seb128: I am poised over the Accept button awaiting your explanation. :)
[17:40] <seb128> SpamapS, I think the code is buggy, it does" write in gsettings if there is a gsettings key otherwise use gconf" but some people will have installed the gsettings schemas on GNOME 2.32
[17:40] <seb128> the same way you can install gtk3 and GNOME 2.32
[17:40] <seb128> they should still write in gconf in the GNOME3 case as well
[17:41] <SpamapS> I did that and it completely screwed my system. ;)
[17:41] <SpamapS> is gsettings in the archive or only in the PPA?
[17:41] <chrisccoulson> seb128 - that's exatly what my background settings patch for firefox does too ;)
[17:41] <mterry> Heyo.  I did test the background thing and it worked, but didn't check into gsettings/gconf
[17:42] <seb128> mterry, well it seems like if gsettings-desktop-schemas got installed and wrote a gsettings key for the background the code would not update the gconf value and your wallpaper wouldn't get updated?
[17:42] <mterry> I believe the gsettings schema for background is only from PPA?
[17:42] <mterry> oh, gsettings-desktop-schemas is in the archive
[17:42] <seb128> mterry, no, gsettings-desktop-schemas is in natty
[17:43] <chrisccoulson> why do we ship the background schema at all if nothing in natty uses it?
[17:43] <mterry> I'm not sure it's installed by default?
[17:43] <seb128> because we landed gtk3 and the bits that can be in the archive directly in the archive
[17:43] <seb128> Reverse Depends:
[17:43] <seb128>   libgnome-desktop-3-0
[17:43] <seb128>   mousetweaks
[17:43] <seb128> seems like mousetweaks depends on it
[17:43] <seb128> so it's likely in the default installation?
[17:45] <seb128> libgnome-desktop-3 also depends on gsettings-desktop-schemas
[17:45] <pitti> Task: ubuntu-desktop, ubuntu-uec-live, edubuntu-desktop, edubuntu-uec-live, ubuntu-netbook
[17:45] <pitti> seb128: ^ yes, in several images
[17:45] <seb128> in practice we could have some gtk2 applications using gsettings and schemas from it
[17:46] <pitti> don't we anyway?
[17:46] <pitti> I remember that we have some packages which reverse-patch the gtk3 specific bits
[17:46] <seb128> we have applications using gsettings, not sure they use gsettings-desktop-schemas
[17:46] <pitti> so they use gtk2, but still gsettings
[17:46] <pitti> ah
[17:46] <seb128> those are desktop keys
[17:46] <seb128> like the background
[17:46] <seb128> or the theme
[17:47] <seb128> we avoided mixing desktop settings in gconf and gsettings
[17:47] <seb128> just to avoid the shotwell case we discuss
[17:47] <seb128> having shotwell writing in gsettings but nautilus still reading gconf
[17:50] <SpamapS> seb128: so, IMO we should report this bug upstream immediately, but move forward with the package in proposed, testing out the possible scenario you're thinking of before moving it to -updates.
[17:50] <seb128> SpamapS, upstream is reading the bug so no need to report it to them, adam is one of the upstream guys
[17:51] <seb128> well if we know it's broken no need to accept it at all
[17:51] <SpamapS> I'm wondering if it is "broken" in any real use case though.
[17:51] <seb128> mterry, can you check the case I described? like if it does update the gconf key if there is a gsettings key?
[17:52] <seb128> glancing over the git commit it seems to return after writing to gsettings in the gsettings case
[17:59] <barry> @pilot in
[18:03] <Sweetshark> pitti: I rechecked all the transitionals and found two additional problems: there is a transitional for zemberek (with we miss in natty) and one for openclipart (causing bug 739839). Any idea about those?
[18:08] <pitti> Sweetshark: I guess same thing -- just drop nonexisting dependencies?
[18:19] <Sweetshark> pitti: openclipart is a bit more tricky: we still have 0.18+dfsg-10, not 0.18+dfsg-11, which generates a "openclipart-openoffice.org_0.18+dfsg-10_all.deb" not a "openclipart-libreoffice..." package. And the openoffice.org source package generates a openclipart-openoffice.org-1:3.3.0-7ubuntu1 transitional that expects the renamed openclipart package.
[18:20] <pitti> Sweetshark: I don't think we should rename the actual package in natty; can we just fix the dependency of teh transitional package to depend again on -openoffice?
[18:20] <Sweetshark> pitti: then it would depend on itself.
[18:21] <pitti> ah, I see
[18:21] <pitti> and the real package has a lower version number
[18:21] <pitti> Sweetshark: then I guess we have to do the renaming in an SRU
[18:21] <Sweetshark> pitti: http://xkcd.com/754/ btw.
[18:22] <Sweetshark> pitti: k
[18:22] <pitti> Sweetshark: i. e. by and large upload -11 with a more SRU-appropriate version number
[18:22] <pitti> 10ubuntu1 or so
[18:22] <pitti> Sweetshark: :)
[18:22] <barry> pitti: hi.  do you have any interest in patches to apport that 1) switch it from pycentral to dh_python2; 2) switch it from cdbs to dh?
[18:23] <pitti> barry: 1) oh please, (2) I was going to, now that we have dh_translations
[18:23] <pitti> barry: so, yes to both
[18:23] <pitti> barry: FYI, I have a local patch for jockey for doing that
[18:23] <pitti> so don't bother with that
[18:24] <barry> pitti: cool.  apport is next on my list of dhpy2 conversions :)  i'm not done with #1 yet, but it's actually easier to also do #2 at same time.  i'll work up a branch for that in the next day or two
[18:24] <barry> pitti: ack for jockey
[18:24] <pitti> barry: agreed, doing both at the same time is easier
[18:24] <barry> pitti: rock.  keep an eye out for merge proposals :)
[18:30] <pitti> SpamapS: I just copied https://launchpad.net/ubuntu/+source/linux-source-2.6.15/2.6.15-57.97 from the canonical kernel PPA using launchpadlib instead of shell access; nice!
[18:30] <pitti> SpamapS: so, time to turn that into a script
[18:31] <SpamapS> pitti: soon we will replace you with a fairly long python script
[18:47] <pitti> SpamapS: mind to update your ubuntu-archive-tools checkout and try to run: ./copy-proposed-kernel.py dapper linux-source-2.6.15
[18:47] <JontheEchidna> Is the app_name field supposed to be empty here: http://reviews.ubuntu.com/reviews/api/1.0/review-stats/ ? I was using it to help differentiate ratings between two apps from the same source package
[18:47] <pitti> SpamapS: it should error out saying that there are binaries being published, but not something like "permission denied" or other stuff
[18:48] <SpamapS> linux-source-2.6.15 2.6.15-57.97 in dapper (same version has unpublished binaries in the destination archive for Dapper, please wait for them to be published before copying)
[18:49] <SpamapS> pitti: :)
[18:49] <pitti> SpamapS: yay
[18:49] <pitti> SpamapS: I didn't yet get the "go!" for the pending natty kernel
[18:50] <SpamapS> pitti: there are two update-manager's in the natty-proposed queue..
[18:54] <micahg> SpamapS: congrats on becoming an archive admin :)
[18:55] <pitti> SpamapS: right, and the second upload doesn't use -v
[18:55] <Laney> "congrats" ;)
[18:55] <pitti> SpamapS: I suggest to reject them both, and ask mvo to reupload
[18:56] <pitti> SpamapS: with either using -v (to catch both changelogs), or merging all changes into 1:0.150.1
[18:57] <SpamapS> micahg: ty :)
[18:57] <SpamapS> pitti: pardon my ignorance, but what do you mean when you say '-v' ? I haven't run into that one.
[18:58] <pitti> SpamapS: dpkg-buildpackage -v<last version in final or -updates>
[18:58] <pitti> SpamapS: to include all releases which are stacking up in -proposed
[18:58] <Sweetshark> pitti: I commited a SRU-able version for bug 772387 and dputted the package to https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-nattytest2 .  How to move on?
[18:58] <SpamapS> pitti: ahh! Ok, yeah I've never had to do that.
[18:58] <pitti> SpamapS: that will (1) give the right display of all changes in update-notifier, and also auto-close all bugs (not just the ones from the latest upload) when copying to -updates
[18:59] <pitti> SpamapS: ... and also show all pending SRU bugs in the report
[18:59] <micahg> SpamapS: it's also used when merging from Debian to catch all the changelogs/close all the bugs
[19:01] <pitti> bjf: let's continue here, not really #release matter
[19:01] <bjf> pitti, ack
[19:01] <pitti> SpamapS: can we copy them right now? or do they still need building/testing?
[19:02] <pitti> sorry, bjf ^
[19:02] <bjf> pitti, just now building, expecting them to ready tomorrow
[19:02] <bjf> pitti, that's why i was asking if you were going to be around
[19:02] <pitti> SpamapS: if the kernel guys (bjf) ask you to move a package from their PPA to -proposed, pending-sru.html gives the necessary commands
[19:02] <pitti> SpamapS: but I think the first time we should do that together
[19:02] <pitti> bjf: would it be too late to do it on Monday?
[19:03] <pitti> bjf: I can certainly copy them tomorrow, that's no problem
[19:03] <SpamapS> pitti: yes, I was thinking that would be something good to work on next week, unless you are more free today/tomorrow
[19:03] <pitti> SpamapS: tomorrow is really bad, need to sort out my moving
[19:03] <bjf> pitti, SpamapS, i think monday would be ok, just the start of the next cycle, will send email to the mailing list with the request and you two can work it from there
[19:03] <pitti> bjf: sounds good
[19:03] <pitti> SpamapS: so, we can do that on Monday then, once you are online?
[19:03] <bjf> pitti, cool
[19:04] <pitti> bjf: unlike dapper, natty won't die tomorrow :)
[19:04] <bjf> pitti, heh
[19:04] <pitti> bjf: speaking of death, what do we do with the current karmic-proposed kernel?
[19:05] <pitti> bjf: should it still run through QA, or do we declare it lost and just keep it where it is?
[19:05] <pitti> (EOL is tomorrow)
[19:05] <bjf> pitti, that is hopefully the last one, it needs testing and then promotion
[19:05] <bjf> pitti, are we too late ?
[19:05] <pitti> ok
[19:05] <SpamapS> pitti: sounds good
[19:05] <bjf> pitti, i don't think anything major went into it
[19:05] <pitti> bjf: well, we technically can USN/release it after April 30, oto
[19:06] <pitti> "too"
[19:06] <SpamapS> pitti: oh, and I hate moving! ;)
[19:06] <bjf> pitti, so, if in the end it just vanishes, i don't think it will be missed
[19:07] <pitti> bjf: just 5 CVEs
[19:07] <pitti> kees: ^ do you have an opinion about the fate of the karmic kernel in -proposed?
[19:07]  * kees reads backscroll
[19:07] <bjf> pitti, yup, no great loss, however, getting it tested and published would be "nice"
[19:07] <pitti> kees: karmic EOL is tomorrow, I wondered if it's worth QA'ing/USNing this still, or just let it die in peace
[19:09] <kees> pitti: I'm on the fence. probably easiest to let it die, but on the other hand, it'd be nice to get that work into -security since it already all happened.
[19:10] <kees> how much is left to QA with it?
[19:10] <bjf> kees, it's kind of been ignored with all the natty testing going on
[19:10] <kees> omg, it's been in -proposed for 5 weeks??
[19:10] <Sweetshark> pitti: should prepare a openclipart 0.18+dfsg-11 renamed to 0.18+dfsg-10ubuntu1 for sponsoring as SRU, or would that help nothing?
[19:10] <bjf> kees, i don't think it would take much, we can talk to pgraner on monday to see if it can get some love
[19:11] <pitti> Sweetshark: not sure whether it's worth doing an SRU just for these two -- perhaps we sohuld wait a couple of days for more issues to come up and bundle them?
[19:11] <kees> bjf, pitti: given that it carries the fix for CVE-2010-4258 I'd prefer it get released.
[19:11] <pitti> Sweetshark: openclipart> that sounds good
[19:11] <pitti> kees: ack
[19:11] <bjf> kees, pitti, i'll talk to pgraner about it
[19:12] <bjf> kees, pitti, ball is in my court
[19:13] <kees> bjf: okay, thanks! if it's really not possible to happen by monday, then it guess it just dies. I don't want to do lots of work on karmic, but it has been in -proposed for a while, it'd be a shame to just drop it.
[19:13] <kees> *I guess it...
[19:17] <pitti> kees: it's not technically a problem to issue an USN after the official EOL, I take it?
[19:17] <speakman> If I'd like to put a new version on a package (for local testing) with current version 0.9.3-3 which would get overwritten when 0.9.3-4 is officially released - what do I choose?
[19:18] <kees> pitti: not exactly, just goofy.
[19:20] <speakman> btw - have you guys discussed the padevchooser icon missing bug?
[19:21] <arand> speakman: 0.9.3-4~ I think
[19:22] <speakman> arand: ok, sounds fair
[19:22] <arand> speakman: Can use 0.9.3-4~ppa1 for example
[19:23] <speakman> arand: Will 0.9.3-4 overwrite 0.9.3-4~ppa1 ?
[19:23] <maco> speakman: -3+ also works
[19:23] <maco> speakman: yes
[19:24] <speakman> maco: 0.9.3-3+ ?
[19:24] <maco> like 0.9.3-3+ppa1
[19:24] <speakman> oh
[19:24] <speakman> Any docs how version numbers are interpreted? :D
[19:24] <maco> that and -4~ppa1 will behave the saem as regards -4
[19:24] <arand> speakman: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version for reference
[19:25] <maco> what i usually do is, if its a test version of what will becomes -4, i use teh ~
[19:25] <maco> but if its a just-for-me modification of the -3, then i use the +
[19:25] <speakman> arand:  thanks :)
[19:27] <speakman> maco: this is a just-for-me modification just to see if it works (and then maybe posting it as an official bug fix patch) :)
[19:27] <speakman> (but it seems like what's really causing https://bugs.launchpad.net/ubuntu/+source/padevchooser/+bug/632468 is a missing sound-card.png icon in the Ambiance theme)
[19:34] <speakman> looks like gnome-icon-theme got audio-card.png (in a varianty of sizes) - how does apps look for images/icons?
[19:36] <maco> speakman: is there a png as an optin?
[19:36] <maco> *option
[19:39] <speakman> maco: I don't know gtk at all, but it seems to be looking for audio-card<anything> at http://git.debian.org/?p=pkg-pulseaudio/padevchooser.git;a=blob;f=src/padevchooser.c;h=89db6977c2e9bb6a28ec0910a7b4298ad9d012c2;hb=HEAD#l534
[19:39] <speakman> maco: and this is my icons available: http://pastebin.com/rTf151BK
[19:39] <speakman> maco: I'm currently on Ambiance theme (default right?)
[20:17] <pitti> slangasek: can multiarch patches be forwarded to Debian now?
[20:20] <slangasek> pitti: they unfortunately can't be applied yet (http://wiki.debian.org/Multiarch/Bootstrapping); they could be forwarded with a caveat
[20:21] <pitti> slangasek: ah, good; did you plan to do a template based mass-forward, or should we forward them during merging?
[20:22] <slangasek> pitti: my plan was to mass-forward them once Debian is ready for them to be uploaded
[20:22] <pitti> ah, that's easier and less error prone
[20:22] <pitti> thanks
[20:22] <pitti> I'll dissect the avahi udeb change then
[20:23] <pitti> slangasek: does that need dh compat 9?
[20:25] <pitti> slangasek: why did you remove all the debian/tmp/ prefixes in *.install files?
[20:25] <slangasek> pitti: dh compat 9 changes the behavior of dh_auto_configure (passing the multiarch --libdir option by default to multiarch); that's what avahi uses it for
[20:27] <slangasek> pitti: because debian/tmp/ is unnecessary with any debhelper compat level >= 7, and it's much uglier; if you revert to using it for merge reasons, the only adverse impact is on legibility
[20:28] <pitti> slangasek: I agree that it's ugly, I just wondered if dh 9 introduced some change there
[20:28] <pitti> slangasek: ok, thanks!
[20:37] <wdbl> Hey guys, congrats on your release. However, if I wanted a Mac, I would have bought one. The nice thing about OS X is not it's global menu bar or it's app-centric window management. Those things actually kinda suck.
[20:39] <maco> yeah, the nice thing about OSX is its accessibility, such as the screenreader that automatically tells you its there if you dont start using the mouse and voices a way to shut if off, rather than forcing some users to go find a sighted friend to turn on a screen reader for them.
[21:02] <Saamm> I got a software center problem...Chromium rating is 102 but it only shows 1....http://i.imgur.com/Nhgpn.png
[21:09] <pitti> james_w`: is it possible to poke lp:ubuntu/cdbs to actually update again?
[21:09] <pitti> james_w`: or can I just push the current version into it?
[21:10] <james_w`> pitti, it is possible
[21:10] <pitti> looks like I could just do import-dsc and push myself, too?
[21:10] <james_w`> done
[21:10] <pitti> or is that discouraged?
[21:10] <james_w`> you could do that
[21:11] <james_w`> if there were merges from Debian in the time that hasn't been imported then it is tricky
[21:11] <pitti> OOI, if it was that quick to poke, what made it fail?
[21:11] <james_w`> it was saying "someone did push --overwrite on the branch, a human should investigate"
[21:11] <pitti> james_w`: I'd like to abandon our custom branch for it, so we'll lose history either way; but merging will be a lot easier with the UDD ones
[21:11] <pitti> james_w`: oh
[21:12] <pitti> james_w`: lp:debian/cdbs is also outdated; same problem?
[21:12] <james_w`> the importer is currently stopped while the new release is being opened
[21:12] <james_w`> yeah, it just leaves everything to do with the package alone if that happens, so that it can't make the problem worse
[21:12] <pitti> james_w`: I mean outdated as in "last commit in 2009"
[21:13] <pitti> james_w`: ah, so same problem, same fix?
[21:13] <james_w`> once the importer starts again it should catch up
[21:13] <pitti> nice, thanks!
[21:13] <james_w`> yeah, packages are global in the importer so the ubuntu branch was overwritten, so it stopped updating debian and ubuntu
[21:13] <james_w`> unblocking it will mean it will update both
[21:13] <james_w`> unless something else causes it to stop of course
[21:18] <speakman> Is there any Ubuntu repository as there is git.debian.org ?
[21:19] <maco> speakman: most ubuntu packages are in bzr
[21:19] <speakman> oh
[21:19] <maco> you can do:      bzr branch lp:ubuntu/packagename
[21:19] <maco> to get trunk
[21:19] <maco> or use lp:ubuntu/maverick/packagename for other release's branches
[21:21] <speakman> thanks alot
[21:21] <speakman> when I remove a patch, do I just do it manually or is there a tool for removing both the .patch file and the entry in "series" file?
[21:23] <speakman> when I install packages using apt-get build-dep - how do I remove then afterwards?
[21:24] <maco> umm...i would do it manually
[21:24] <maco> there's probably a quilt-y way
[21:25] <speakman> oh :)
[21:25] <maco> as to apt-get build dep... i would copy and paste the package list at install time to file then cat that through apt-get remove
[21:25] <pitti> that's what I do; sudo dpkg -P $(< purge.txt)
[21:25] <Nafallo> pbuilder ftw?
[21:26] <speakman> Ok, I've done "apt-get source padevchooser", removed the errnous patch, added a new entry in debian/changelog using "dch -i" and describe my changes. Shouldn't "debuild" do the trick now?
[21:27] <azeem> speakman: what's the problem?
[21:28] <arand> speakman: It should, normally.
[21:29] <speakman> http://paste.ubuntu.com/600442/
[21:30] <speakman> It's straight from the bzr repo
[21:31] <arand> speakman: Either export a clean directory without .bzr or use bzr-buildpackage (I think it's called).
[21:31] <pitti> speakman: you should install bzr-builddeb and use bzr bd -S (source) or -b (binary build)
[21:32] <pitti> speakman: that'll do the necessary tricks
[21:32] <pitti> speakman: it'll also build binaries in a separate build tree, so that they won't mess up your original source dir (autoconf noise, etc.)
[21:32] <maco> i always forget to warn people about that
[21:33] <speakman> wow great
[21:33] <speakman> but it complains about missing my removed patch file... hmmm
[21:34] <pitti> speakman: ah, for removals you have to commit your change first
[21:34] <pitti> speakman: (or additions)
[21:34] <pitti> mere changes will build fine before committing, too, but it's not _that_ magic
[21:34] <speakman> :D
[21:35] <speakman> Can I --amend a commit in bzr?
[21:36] <pitti> speakman: not that I know of; you can bzr uncommit, and commit again
[21:36] <speakman> Hm. Can I skip the signing part? I don't really have any official gpg keys...
[21:36] <pitti> speakman: yes; bzr bd -S -- -us -uc
[21:36] <speakman> (although I originally had a pair, I've no idea where they are these days)
[21:36] <speakman> thanks :)
[21:37] <pitti> for merely building a local package without a patch, this is a lot of overhead, FTR; apt-get source, remove patch, debuild would have been a lot easier :0
[21:37] <maco> speakman: did you bzr rm or just rm?
[21:37] <speakman> rm, but I think bzr grabbed it anyway
[21:37] <pitti> rm plus commit works fine, yes
[21:38] <speakman> Hm, why does packages compile with -g ?
[21:39] <pitti> speakman: standard Debian policy, to make it easier to debug them; but by default dh_strip strips the binaries
[21:39] <pitti> speakman: i. e. to retain the symbols, you merely need to set DEB_BUILD_OPTIONS=nostrip (which dh_strip checks for)
[21:39] <speakman> oh, I see. :)
[21:40] <pitti> without the need to change any build options
[21:40] <speakman> Now it seems like bzr bd falls through - but...where's the .deb file? :D
[21:40] <pitti> should be in ..
[21:40] <pitti> or in ../build-area/
[21:40] <maco> either of you know the keyboard sequence to switch to classic ubuntu from gdm?  must be keyboard, user is blind
[21:41] <speakman> ../build-area/ it was! Thanks!
[21:41] <maco> (why dont we have a screenreader on gdm?)
[21:42] <pitti> maco: hm, it doesn't actually seem to be possible :/
[21:42] <maco> O_O
[21:42] <maco> there's no keyboard way to open the options menu?
[21:42] <speakman> Ok, seems like padevchooser finally did get an icon (although nothing matching the ubuntu original theme). How do I propose my changes to the ubuntu maintainer..?
[21:43] <maco> speakman: push your branch to launchpad (bzr push lp:~yourusername/packagename/branchname), link it to the bug, and make a merge request
[21:43] <speakman> ok, thanks. How should I mention the bug in the commit message? There are at least three different methods currently.
[21:44] <speakman> "Closes: #12345" or "Fixes: #12345" or "LP: #12345" or just "fixes bug(s): https://lp.net/bugs/12345" ?
[21:44] <pitti> speakman: preferred method is to make an appropriate changelog entry (with "dch") and close the bug in it with * Fixes describe me.. (LP: #123456)" (please use the exact LP: # syntax)
[21:44] <pitti> speakman: then use debcommit, this will automatically link the commit to the bug
[21:45] <pitti> speakman: Closes: is for Debian bugs, LP: # for Ubuntu bugs
[21:45] <maco> speakman: if you've already committed without debcommit but have it in changelog already, you can also do --fixes lp:12345
[21:45] <pitti> the other two aren't recognized by tools
[21:45] <maco> oh wait youd still need to commit to use --fixes
[21:45] <maco> you can also manually link to bugs on lp
[21:45] <pitti> that, too
[21:46] <speakman> I have to edit the changelog and alter my latest commit. How do I do that in bzr? Similar to git commit --amend ?
[21:46] <maco> just edit it and make another commit
[21:46] <maco> nothing wrong with having more than one commit in your merge request
[21:48] <speakman> bzr uncommit ; debcommit did the trick :)
[21:49] <speakman> maco: I just prefer not to expose my mistakes :D (bad git habit I guess)
[21:49] <pitti> ScottK: do you know if we still actually use cdbs' kde.mk.in and/or kde4.mk.in? kdebase uses /usr/share/pkg-kde-tools/qt-kde-team/1/debian-qt-kde.mk
[21:49] <pitti> Riddell: ^
[21:49] <ScottK> Those are meant primarily for non-core KDE packages that are distributed by third parties.  We'd have go grep debian/rules to know I think.
[21:50] <pitti> ScottK: by "third parties" you mean non-ubuntu sources?
[21:50] <ScottK> I mean non-KDE core stuff.
[21:51] <pitti> we have a ridiculous cdbs delta, I'm trying to reduce it a bit; the langpack.mk stuff can already go
[21:51] <speakman> bzr: ERROR: Invalid url supplied to transport: "lp:~speakman/padevchooser/drop-use_stock_gnome_icons.patch": No such project: padevchooser
[21:51] <pitti> speakman: try lp:~speakman/ubuntu/natty/padevchooser/drop-use_stock_gnome
[21:51] <ScottK> It would be non-trivial to answer your question.  If Debian dropped it, then it's reasonably safe for use to do so.
[21:51] <maco> oh cuz that expects project there....
[21:51] <pitti> ScottK: Debian never had it
[21:51] <maco> pitti: this ends up silly-long haha
[21:51] <ScottK> Hmmm.
[21:52] <pitti> maco: I think there's a shortcut for this, but I don't remember
[21:52] <abhinav-> pitti: do you have sometime ? :)
[21:52] <ScottK> pitti: Then I'm misremembering and I'm on a $work deadline right now, so ENOTIME to research it.
[21:52] <pitti> for the "official" branch you can just do bzr get ubuntu:pkgname
[21:52] <speakman> And there it is: https://code.launchpad.net/~speakman/ubuntu/natty/padevchooser/drop-use_stock_gnome_icons.patch :D
[21:52] <pitti> ScottK: ok, thakns
[21:52] <maco> pitti: right, i know the getting shortcut, but...is there a pushing shortcut?
[21:52] <pitti> maco: I don't know
[21:53] <pitti> maco: I'm not using these often -- I just upload :)
[21:53] <pitti> usually I'm on the merging/sponsoring side of the fence
[21:54] <maco> im usually bugging ScottK when i want a main sponsor, and he hates UDD so if i use it im on that side of things too
[21:55] <Laney> :parent? or is that something else?
[21:55] <speakman> maco: may I ask how to "link" my branch to the bug?
[21:55] <maco> speakman: click on the branch on your code page on lp. should be an option to do it there i think
[21:55] <speakman> maco: Oh, it has been automatically linked to the bug
[21:55] <maco> a green + button
[21:55] <maco> oh well then youre done
[21:55] <maco> well mostly
[21:55] <speakman> maco: https://code.launchpad.net/~speakman/ubuntu/natty/padevchooser/drop-use_stock_gnome_icons.patch
[21:55] <maco> do the merge request
[21:55] <speakman> ok :)
[21:56] <pitti> ScottK, Riddell: I checked a few more packages; I'll take a plunge and drop them for now, and commit to putting them back if needed
[21:56] <ScottK> Fair enough.
[22:20] <barry> @pilot out