[15:38] <akgraner> pleia2, hey
[15:38] <akgraner> how can I help - happy too
[15:38] <akgraner> working on my office today so I'll have some time if you need me
[15:39] <pleia2> akgraner: thanks :) I haven't even looked at the doc yet today, I'll let you know :)
[15:39] <akgraner> bkerensa, congrats again on your talk - I can't wait to see it the recording of it
[15:39] <akgraner> pleia2, awesome!  I'm just a ping away :-)
[15:43] <Silverlion> akgraner: hey ;)
[15:44] <akgraner> Silverlion, hey :-)
[15:44] <Silverlion> FINALLY! she recognizes me :D
[15:44] <akgraner> :-P
[15:46] <akgraner> Silverlion, I'm putting my office back together (before my company shows up) and checking on various thinks a little at a time...Let me find an hour to just be present and we'll finish the interview and I'll get it to Ronnie
[15:48] <Silverlion> akgraner: just let it be as it is ;) i just got the articles for the upcoming issue #63 of the mag... so the next two weeks I will be busy as well
[16:06] <pleia2> oh, and I realized alpha3 isn't this thursday, it's *next* thursday, my July is full of crazy, I don't know what day it is :)
[16:07] <pleia2> I'll be around
[16:10] <nhandler> pleia2: Alright. I'll be around as well. And shouldn't bkerensa be back too? Maybe he should prepare the post to get the experience ;)
[16:12] <pleia2> nhandler: +1
[16:36] <s-lion> pleia2: ping
[16:36] <pleia2> s-lion: pong?
[16:37] <s-lion> just saw your link to ubuntu women and that you plan to get a german side
[16:37] <s-lion> need translation help?
[16:38] <pleia2> what link?
[16:38] <s-lion> http://wiki.ubuntu-women.org/Home
[16:39] <pleia2> ah, yeah, translations are always good, details are here: http://wiki.ubuntu-women.org/Translators
[16:39] <pleia2> I don't actually know much about translations, so I can't be very helpful
[16:40] <s-lion> i will see through after my projects ... if any urgent help needs then ping me
[16:41] <pleia2> oh no, it's certainly not urgent :) the option to translate our wiki has been around since the beginning of our project (2006)
[16:43] <s-lion> ;)
[16:56] <pleia2> akgraner: my editing eyeballs would love a week off, so if you could review and copy articles from the Google doc over to the wiki that'd be great :)
[17:06] <nhandler> pleia2, akgraner: I just copies the google doc to the wiki (not sure if I should wipe the gdoc now). I did not do any review at this time though
[17:06] <pleia2> ok, thanks (we usually do our first review in the google doc itself, but that's fine :))
[17:07] <pleia2> but yeah, you should wipe the articles from the doc so people know not to edit them anymore
[17:41] <pleia2> I went ahead and deleted them (one of the editors was still making changes, so I'm copying those over now and fixing up the wiki syntax
[17:46]  * pleia2 works on stats
[18:05] <pleia2> ok, those are set
[18:26] <akgraner> pleia2, review from the wiki then?
[18:26] <pleia2> akgraner: yeah
[18:26] <akgraner> k
[18:28] <akgraner> pleia2, want me to take out "Welcome new members and move some of the top stories from the other sections to the GCN section?
[18:28] <pleia2> akgraner: yeah, go for it
[18:28] <akgraner> (well once I get finished with the review)  - ok
[18:29] <akgraner> pleia2, I'll ping once I am finished
[18:31] <pleia2> thanks
[18:31] <pleia2> then I'll email our other editors :)
[18:47] <akgraner> pleia2, it's saving now
[18:48] <akgraner> pleia2, done and you ready to send to the other editors
[18:48] <pleia2> akgraner: awesome, thanks!
[18:49] <akgraner> yw :-)  let me know if you need anything else  - I'll be online around 5am my time if you need me to publish or anything - you'll be at OSCON right?
[18:49] <pleia2> akgraner: nah, I'm only attending thursday and friday
[18:50] <pleia2> (already took vacation time this month, taking a whole week for a last minute conference was too much)
[18:50] <akgraner> pleia2, gotcha
[18:56] <akgraner> yeah - I have to take 2 days next week and 10 days in August, time off is soooo easy to go through.  :-)
[18:58] <pleia2> more of it would be nice :)
[19:00] <pleia2> ok, break from computer time now, bbl :)


[00:42] <valorie> Riddell: soooo much faster or further each day than his estimate
[00:44] <valorie> weee, and new blogs up
[00:45] <shadeslayer>   /join #kde-devel
[00:47] <valorie> :-)\
[00:57] <Riddell> uploading plasma 5.3.1 to wily!
[00:58] <Riddell> valorie: url?
[01:00] <valorie> http://bobofwashington.blogspot.com
[01:01] <valorie> he's overusing "beautiful" and "breathtaking" quite a bit this week
[01:01] <valorie> but the photos are fantastic
[01:03] <valorie> oops, gotta get on the road to my daddy's
[01:19] <Riddell> very bonny
[01:48] <sebas> stunning photos really
[02:59] <sitter_> wgrant: I think there might be a problem with the sftp incoming server thing tech. I am seeing dput not returning even though it finished uploading for sometimes up to half an hour. other times it works fine. http://kci.pangea.pub/view/vivid%20FIX/job/vivid_unstable_kfilemetadata/57/console at 02:31:26 for example, the next output is happening exactly after the waitpid() call returns
[02:59] <sitter_> also nothing changed on our server side FWIW
[03:04] <wgrant> sitter_: Have you seen it happen before?
[03:06] <sitter_> wgrant: it has been happening all day, but from what I can tell not for all builds
[03:07] <[Relic]> just making certain, the bug tracker has a different login than the rest of the kde site (thought it was going to a single login, but not sure since I haven't accessed it in a while)
[03:08] <sitter_> wgrant: http://kci.pangea.pub/job/vivid_stable_kwin/70/console 04:13
[03:08] <sitter_> oh actually
[03:09] <sitter_> wgrant: I probably shouldn't exclude a change in dput/perl as the cause, the containers get auto updated every once in a while
[03:09]  * sitter_ checks vivid
[03:09] <sitter_> ah wait, that is vivid xD
[03:09] <sitter_> so probably not dput after all
[03:10] <wgrant> sitter_: "Successfully uploaded packages" sounds like dput is done, to me.
[03:10] <sitter_> and yet it doesn't as indicated by the delay
[03:11] <sitter_> wgrant: I'll try to eleminate all other possible causes and get back to you I guess
[03:11] <wgrant> sitter_: That'd be helpful. Check if dput is actually running, if it has a connection open, etc.
[03:12] <wgrant> sitter_: All three connections created around that time are closed from our end, AFAICS.
[03:12] <sitter_> ok
[03:38] <ahoneybun> hello all
[09:15] <soee> good morning
[10:23] <lordievader> Good morning.
[11:01] <sick_rimmit> Hello friends :-)
[11:02] <lordievader> o/
[12:59] <BluesKaj> Hi folks
[14:41] <sick_rimmit> BluesKaj: Hello my friend, didn't notice you arrive :-)
[14:43] <BluesKaj> hey sick_rimmit , what's up ?
[14:49] <sick_rimmit> BluesKaj: Been having fun creating documentation auto gen jobs with Jenkins today, you ?
[14:49] <Riddell> Number of "Yes" votes: 64 (85.33%)
[14:49] <Riddell> Number of "No" votes: 0 (0.0%)
[14:49] <Riddell> yay sgclark is in!
[14:49] <BluesKaj> mostly just chatting in offtopic atm
[14:50] <sick_rimmit> Riddell: What is she in please ?
[14:50] <BluesKaj> congrats sgclark!
[14:50] <Riddell> kde e.v.
[14:51] <sick_rimmit> Oh definetly well deserved, congrats sgclark :-)
[14:51] <Riddell> clivejo: hi, how did you get on with kamoso?
[14:52] <clivejo> Riddell: give up!
[14:52] <Riddell> clivejo: aww, where did you get stuck?
[14:53] <clivejo> waiting for deps
[14:53] <Riddell> clivejo: do you know which ones?
[14:54] <clivejo> Plasma 5.3.1 I believe
[14:55] <Riddell> we should have that available now
[14:56] <clivejo> I havent looked since, been working on few OSM tasks
[14:57] <Riddell> clivejo: do you want to work on it together?
[14:57] <clivejo> have you time?
[15:00] <Riddell> clivejo: sure
[15:00] <Riddell> clivejo: let me set up an ec2
[15:00] <clivejo> Riddell: on wily Im getting an error in Kleopatra about pgp-agent not able to connect (IPC call)
[15:00] <clivejo> is this a local config error, or devel ?
[15:00] <Riddell> clivejo: oh that's just the signing stage, if you get to that it means it's all done
[15:00] <Riddell> local config error
[15:01] <clivejo> this is a different issue
[15:01] <clivejo> more to do with Kmail
[15:02] <Riddell> kleopatra is the pgp signing part of kdepim
[15:02] <Riddell> at the end of making a packaging it'll try to sign it with pgp/gpg
[15:02] <clivejo> I was having problems with purpose
[15:03] <clivejo> apparently its a separate lib ?
[15:03] <Riddell> yes it is
[15:04] <clivejo> it was failing on KDE Connect
[15:04] <clivejo> and Ubuntu account
[15:04] <clivejo> oh its building now
[15:04] <clivejo> oh, maybe not
[15:05] <clivejo> /usr/include/KAccounts/getcredentialsjob.h:26:28: fatal error: Accounts/Account: No such file or directory
[15:10] <Riddell> clivejo: ssh<EMAIL_ADDRESS>[15:12] <Riddell> clivejo: can you scp your .dsc .debian.tar.gz and .orig. to that server?
[15:13] <clivejo> are you building purpose?
[15:14] <Riddell> clivejo: nope I'm waiting for you to copy it to the server so we can built it there :)
[15:15] <clivejo> what arch is the VPS?
[15:15] <Riddell> the server looks to be amd64
[15:21] <clivejo> Riddell: is that naming correct?
[15:21] <Riddell> not quite, let me try
[15:21] <clivejo> grrr
[15:22] <Riddell> clivejo: voila, the alpha needed a ~ to indicate it's less than 1.0
[15:25] <clivejo> sorry, trying to find package
[15:26] <Riddell> you'll have a .debian.tar.gz where you were building it on your machine
[15:27] <clivejo> yes, but I had questions about it
[15:27] <clivejo> https://launchpad.net/~kubuntu-ci/+archive/ubuntu/unstable/+build/7509702
[15:27] <clivejo> the name?
[15:27] <clivejo> is it supposed to be libkf5purpose?
[15:27] <clivejo> or just purpose
[15:32] <Riddell> the source is just purpose
[15:32] <clivejo> Im really confused
[15:33] <Riddell> clivejo: do you have the packaging?
[15:34] <clivejo> the dget ?
[15:34] <clivejo> I cant find the one I was working with
[15:35] <clivejo> I copy debain to the new ?
[15:36] <Riddell> yep
[15:37] <Riddell> clivejo: cp into .
[15:37] <clivejo> thanks
[15:38] <clivejo> these version numbers confuse the hell outta me
[15:38] <clivejo> do I keep the original upstream?
[15:39] <Riddell> yes, which is 0.1~alpha
[15:39] <clivejo> ie 0.1 alpha?
[15:39] <Riddell> we wrongly assumed upstream would use 5.9 so that's why the ci packaging has that
[15:39] <Riddell> morning sick_rimmit
[15:39] <Riddell> morning sitter too
[15:42] <clivejo> is that ok?
[15:43] <Riddell> clivejo: needed some spaces in places
[15:43] <Riddell> it's quite fussy about the exact format
[15:44] <Riddell> clivejo: debuild ?
[15:44] <clivejo> do I not need to keep the fact that you are the original package builder?
[15:44] <Riddell> nah
[15:44] <Riddell> I think I'm famous enough after this week :)
[15:46] <BluesKaj>  I had a friend who moved a lot , he used to say, "when I become too famous , I move" , he was definitely a loner and still is.
[15:47] <Riddell> hmm  E: Unable to locate package libkaccounts-dev
[15:47] <clivejo> is this wily?
[15:48] <Riddell> mm it is
[15:48] <Riddell> where I don't think that's packaged yet
[15:48] <Riddell> so maybe I should do kde applications and then we'll come back to this
[15:49] <clivejo> its ok on mine
[15:49] <clivejo> but I have the PPA on mine
[15:49] <clivejo> staging 2
[15:50] <Riddell> ah hah, good old sgclark has done it already
[15:51] <Riddell> clivejo: seems to be doing it
[15:51] <clivejo> indeed
[15:51] <clivejo> is there an easy way to install all deps?
[15:52] <clivejo> QMLModule?
[15:53] <clivejo> boy you're fast
[15:54] <Riddell> clivejo: alas there's not
[15:54] <Riddell> I had to do some detective work on that
[15:54] <clivejo> stilln not ?
[15:54] <Riddell> hmm noi :(
[15:55]  * sick_rimmit waves at eveyone he ignored in the last 30 mins
[15:55] <clivejo> hi rick
[15:55] <sick_rimmit> hey clivejo
[15:57] <clivejo> Riddell: could it be accounts-qml-module ?
[15:58] <Riddell> src/plugins/CMakeLists.txt:find_package(QMLModule 0.1 COMPONENTS Ubuntu.OnlineAccount)
[15:58] <Riddell> src/plugins/CMakeLists.txt:find_package(QMLModule 1.0 COMPONENTS org.kde.kdeconnect)
[15:58] <Riddell> it's those two module it's looking for
[15:58] <clivejo> yup thats where I failed too
[15:59] <clivejo> sorry typing over you
[15:59] <Riddell> I think I tracked them down running locale on my local computer
[16:00] <sitter> Riddell: we need different CI for arm
[16:00] <Riddell> sitter: why?
[16:00] <clivejo> where did you find them?
[16:00] <sitter> Riddell: too slow, way way way too slow
[16:00] <Riddell> welcome to arm
[16:01] <sitter> no
[16:01] <sitter> it's WAY too slow
[16:01] <sitter> http://kci.pangea.pub/job/vivid_unstable_kwin/138/
[16:01] <sitter> time stamp upper right corner
[16:01] <clivejo> ah I see
[16:01] <Riddell> clivejo: yay it worked :)
[16:02] <Riddell> clivejo: such is the life of a packager, some detective work may be needed
[16:02] <clivejo> finally!
[16:02] <Riddell> clivejo: in this case I had to read the cmake file to work out what it wanted and them track down those files
[16:02] <Riddell> and work out what packages they're in
[16:02] <Riddell> http://packages.ubuntu.com is often useful for that
[16:02] <clivejo> how do you work out the packages they are in?
[16:03] <clivejo> thats my last errors!
[16:03] <clivejo> Accounts/Account
[16:03] <Riddell> I did  dpkg -S org.kde.kdeconnect
[16:04] <Riddell> clivejo: more detective work needed here, I know apol mentioned a patch was needed to work with the current version of something, so I guess this is it
[16:06] <Riddell> actually it looks like a problem in kaccounts
[16:07] <Riddell> so I'm asking mck182 who is the kaccount dude
 Riddell: probably purpose missing some Accounts-Qt includes
[16:10] <Riddell> clivejo: I think I tracked it down with http://packages.ubuntu.com
[16:10] <Riddell> but let's see if it compiles now
[16:10] <clivejo> what does purpose even do?!?
[16:11] <Riddell> it's a replacement for kipi-plugins
[16:12] <clivejo> bar generate LOTS of errors
[16:12] <Riddell> damn, same problem
[16:12] <clivejo> Accounts/Account, is that a local include file?
[16:13] <mck182> no, it comes from accounts-qt5
[16:13] <mck182> $installdir/include/accounts-qt5/Accounts/Account
[16:19] <Riddell> hmm it's still not finding it
[16:20] <clivejo> Riddell: Im gonna have to go
[16:20] <clivejo> got company in 10 mins
[16:20] <Riddell> clivejo: ok dokay, I'll take a break too, I'll let you know if I progress or you can use this server whever you are free too
[16:20] <clivejo> please do
[16:20] <Riddell> clivejo: they're not usually this tricky :)
[16:20] <clivejo> this was driving me crazy
[16:21] <clivejo> bye for now
[16:22] <Riddell> yep just needs -I/usr/include/accounts-qt5/ added to the include path
[16:22] <Riddell> mck182: what's the easiest way to do that?
[16:22] <mck182> Riddell: add it to compiler flags?
[16:23] <mck182> -DCMAKE_CXX_FLAGS I think
[16:25] <mck182> -DCMAKE_CXX_FLAGS="-I/usr/include/accounts-qt5/" to be exact
[16:30] <sitter> wgrant: what are the chances of getting native arm builders for the kubuntu CI rather than emulated?
[17:57] <Riddell> claydoh: yay compiled it!
[20:15] <murthy> Trying to compile libarchive from master, some tests fail, need help . This is the error output https://paste.kde.org/pv9ydburd
[22:14] <wgrant> sitter: Very low right now, but we'll have generally available real VMs in a month or two.
[22:21] <sitter> wgrant: ok thanks
[22:21] <sitter> Riddell: ^ FTR
[22:23] <wgrant> We have the hardware in the DC, finally, but not quite set up yet.
[22:25] <Riddell> interesting
[22:25] <Riddell> question is which will happen first, this plasma-workspace compile or the new hardware installed :)
[22:26] <wgrant> Heh
[22:26] <wgrant> Be glad it's qemu and not some horrible ARM simulator.
[22:26] <wgrant> When we were doing the arm64 port, the first gcc build took 19 days and then failed...
[22:26] <sitter> actually qemu-arm segfaults on all qapps xD
[22:26] <sitter> so there's that ;)
[22:26] <wgrant> Yup, qemu-user-static doesn't love multithreading :/


[01:25] <evand> cjwatson: Hrm, migration-assistant doesn't currently report the size of things it's going to import to the installer.  I could implement this over next week (Spring Break here) for most items.
[01:26] <evand> Unless of course you think it's too risky so close to release, in which case I would recommend modifying the warning in the new partitioner to say, "at least 2GB and enough space for any data you have chosen to import from your previous OS" or something to that effect.
[05:54] <joejaxx> cjwatson: do you have any links to the documentation on the debian install cd building process? other than the debian wiki
[08:16] <john> what do I need to add to my /etc/apt/sources.list  to be able to install streamripper with apt-get?
[09:46] <cjwatson> evand: do we import data yet, or just settings?
[09:47] <cjwatson> joejaxx: no, that and the documentation in debian-cd itself are all I know of
[09:47] <cjwatson> john: no idea - this channel's for full OS installation rather than figuring out how to install particular packages
[10:50] <CIA-4> ubiquity: cjwatson * r1912 ubiquity/debian/ (changelog control): * Add XS-Vcs-Bzr field to debian/control.
[12:21] <CIA-4> ubiquity: cjwatson * r1913 ubiquity/debian/changelog: reorg
[12:23] <CIA-4> ubiquity: cjwatson * r1914 ubiquity/ (debian/changelog ubiquity/frontend/gtkui.py): - Add more space around text in question dialogs.
[12:26] <CIA-4> ubiquity: cjwatson * r1915 ubiquity/ (configure configure.ac): bump to 1.3.25
[01:19] <CIA-4> ubiquity: cjwatson * r1916 ubiquity/ (82 files in 4 dirs):
[01:19] <CIA-4> ubiquity: * Automatically unmount mounted partitions if they are on a changed
[01:19] <CIA-4> ubiquity:  partition table or they are to be mounted somewhere other than /media/*.
[01:19] <CIA-4> ubiquity:  Display an error and allow the user to try to unmount them manually if
[01:19] <CIA-4> ubiquity:  automatic unmounting fails (LP: #89605).
[01:58] <evand> cjwatson: My Documents, My Pictures, and My Music, so yes, we import data as well.
[02:01] <cjwatson> evand: ok, so perhaps report the size (shove it in the debconf db somewhere) but don't change the partitioner yet? That should obviously be minimally safe, means the partitioner can be changed independently, and that warning needs to be reimplemented properly for the new partitioner anyway ...
[02:16] <evand> cjwatson: ok, will do
[02:17] <evand> thanks
[02:27] <CIA-4> ubiquity: cjwatson * r1917 ubiquity/debian/changelog: note fix for LP: #90276
[03:48] <CIA-4> ubiquity: cjwatson * r1918 ubiquity/ (4 files in 3 dirs):
[03:48] <CIA-4> ubiquity: * Work around datetime misbehaviour if the system clock is set before the
[03:48] <CIA-4> ubiquity:  Unix epoch (LP: #57952).
[04:00] <CIA-4> ubiquity: cjwatson * r1919 ubiquity/ (d-i/manifest debian/changelog):
[04:00] <CIA-4> ubiquity: * Automatic update of included source packages: console-setup 1.13ubuntu7,
[04:00] <CIA-4> ubiquity:  localechooser 1.37ubuntu1, migration-assistant 0.4.1, partman-auto
[04:00] <CIA-4> ubiquity:  62ubuntu6, partman-base 100ubuntu6, partman-efi 11ubuntu3.
[04:08] <CIA-4> ubiquity: cjwatson * r1920 ubiquity/d-i/get-sources: make sure to remove d-i/source/console-setup/.svn
[04:21] <CIA-4> ubiquity: cjwatson * r1921 ubiquity/ (d-i/manifest debian/changelog): * Automatic update of included source packages: partman-base 100ubuntu7.
[04:25] <CIA-4> ubiquity: cjwatson * r1922 ubiquity/debian/changelog: releasing version 1.3.25
[04:33] <CIA-4> ubiquity: cjwatson * r1923 ubiquity/ (configure configure.ac): bump to 1.3.26
[04:52] <joejaxx> cjwatson: alright thanks
[05:00] <CIA-4> ubiquity: cjwatson * r1924 ubiquity/ (bin/ubiquity debian/changelog): * Make acquire_lock properly atomic (LP: #90391).
[10:50] <CIA-4> ubiquity: cjwatson * r1925 ubiquity/ubiquity/frontend/ubiquity.glade: open/save in glade-3
[11:06] <CIA-4> ubiquity: cjwatson * r1926 ubiquity/ (3 files in 2 dirs):
[11:06] <CIA-4> ubiquity: * GTK frontend: Remove the disk bar placeholder for the new partitioner;
[11:06] <CIA-4> ubiquity:  we'll probably have to do without the disk bar for Feisty at this point.


[03:58] <pleia2> Welcome to the Ubuntu Weekly Newsletter, Issue 387 for the week October 6 - 12, 2014 https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue387
[06:11] <Unit193> pleia2: https://lists.ubuntu.com/archives/precise-changes/2014-October/022840.htm that's a dud.
[06:11] <Unit193> (s/htm/html/
[06:11] <Unit193> )
[15:38] <PaulW2U> Unit193: pleia2: bad link corrected on wiki
[16:19] <pleia2> thanks Unit193 and PaulW2U


[00:42] <StevenK> wgrant: factory.makeAccessPolicyGrant() is giving me ClassInfoError: <type 'zope.security._proxy._Proxy'>.__storm_table__ missing
[00:45] <wgrant> StevenK: How're you calling it?
[00:45] <StevenK>         self.factory.makeAccessPolicyGrant(
[00:45] <StevenK>             policy=ap, grantee=subscriber, grantor=product.owner)
[00:46] <wgrant> StevenK: Can I see the whole test?
[00:48] <StevenK> wgrant: http://pastebin.ubuntu.com/1137210/
[00:50] <wgrant> StevenK: line 22
[00:50] <wgrant> [ap] =
[00:50] <wgrant> Rather than ap =
[00:50] <wgrant> find returns a resultset.
[00:50] <StevenK> Ah!
[01:08] <cjwatson> wgrant: https://code.launchpad.net/~cjwatson/launchpad/publishinghistory-show-copier/+merge/118223 is worth looking at again now, I think.
[01:09] <cjwatson> It's a bit longer in terms of LoC, but I have more credit now anyway :)
[01:10] <lifeless> mm
[01:10] <lifeless> you know the goal is overall reduction not stasis
[01:10] <cjwatson> I know, but I'm well over 4000 down, I'm making considerably more net progress than most Launchpad developers ;-)
[01:12] <cjwatson> (At least on this metric)
[01:13] <lifeless> \o/
[01:14] <lifeless> thats excellent
[01:14] <lifeless> we're what, 1% of the way there
[01:14] <cjwatson> About -0.4%.
[01:14] <cjwatson> http://people.canonical.com/~cjwatson/tmp/loc-cum.png
[01:31] <wgrant> cjwatson: Looking at your MP
[01:35] <cjwatson> Blast.  Anyone want to hazard a guess as to why r15769 hasn't produced an improved oops notification on https://qastaging.launchpad.net/~cjwatson/+archive/ppa/+packages
[01:35] <cjwatson> ?
[01:37] <wgrant> It may be wise to confirm that gandwana's up to date
[01:37] <wgrant> I believe that it sometimes lags an update behind asuka
[01:37] <wgrant> But I've never been able to confirm it
[01:38] <wgrant> cjwatson: ^^
[01:38] <cjwatson> I was going to look at https://devpad.canonical.com/~wgrant/production-revnos but it's showing a Python traceback.
[01:38] <wgrant> cjwatson: That also doesn't show staging stuff
[01:38] <wgrant> Since they're deployed by an entirely separate system, for not very good reasons
[01:39] <wgrant> In fact, by two entirely separate systems.
[01:39] <cjwatson> Yeah, I thought it might not, but also that you might want to know about the traceback :)
[01:39] <wgrant> Indeed, thanks.
[01:41] <wgrant> Ah
[01:41] <wgrant> cron-control on the frontends is breaking it
[02:29] <StevenK> wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/redirect-unsub-private-branch/+merge/118859
[03:27] <wallyworld_> StevenK: sorry, was having lunch, looking now
[03:35] <wallyworld_> r=me
[03:43] <StevenK> wallyworld_: Thanks!
[03:43]  * StevenK tosses it at ec2.
[04:07] <StevenK> wgrant: Can you make sense of bug 834370?
[04:07] <_mup_> Bug #834370: factory.makeSPPHForBPPH is incomplete <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/834370 >
[04:10] <wgrant> StevenK: I am confuse.
[04:15] <StevenK> wgrant: Oh?
[04:15] <wgrant> StevenK: It doesn't make sense.
[04:15] <wgrant> SPPHs don't have arches...
[04:16] <StevenK> Right.
[04:16] <wgrant> Maybe bigjools knows.
[04:16] <bigjools> it wasn't me.
[04:16] <StevenK> I'm tempted to just rip out the method. It has exactly one callsite.
[04:16] <bigjools> what was the question
[04:16] <StevenK> bigjools: bug 834370
[04:17] <_mup_> Bug #834370: factory.makeSPPHForBPPH is incomplete <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/834370 >
[04:17] <bigjools> ummm
[04:17] <bigjools> without looking at code, s/architectures/archives/ ?
[04:18] <StevenK> It respects bpph.archive
[04:18] <bigjools> bug description fail
[04:19] <bigjools> I'm sure it was valid at the time but no memory is being jogged
[04:19] <bigjools> builds?
[04:19] <StevenK> It references bpr.build.spr
[04:19] <bigjools> I dunno then
[04:20] <wgrant> Yeah
[04:20] <wgrant> It all looks pretty sensible to me.
[04:20] <wgrant> So I don't get it.
[04:20] <bigjools> maybe it got fixed
[04:20] <StevenK> Still tempted to rip it out
[04:20] <bigjools> and the bug was not updated
[04:20]  * bigjools continues with maas bugs
[04:36] <wgrant> StevenK, wallyworld_: https://code.launchpad.net/~wgrant/launchpad/noro/+merge/118867 ← 1369 lines (+19/-889) 22 files modified
[04:37] <StevenK> I already approve
[04:39] <StevenK> wgrant: r=me
[04:41] <wgrant> Thanks.
[04:53] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/noro-config/+merge/118869
[04:55] <lifeless> https://code.launchpad.net/~lifeless/lp-dev-utils/ppr/+merge/118870
[04:55] <lifeless> wgrant: ^ while you wait for StevenK  :)
[04:55] <StevenK> 114	- database_name = ConnectionString(dbconfig.rw_main_master).dbname
[04:55] <StevenK> 115	+ database_name = ConnectionString(dbconfig.main_master).dbname
[04:55] <StevenK> wgrant: ^ Que?
[04:56] <wgrant> StevenK: Observe the comment above it.
[04:56] <wgrant> StevenK: It was avoiding the usual main_master property, since it always wanted RW
[04:57] <wgrant> lifeless: Did you just like make lp-dev-utils depend on all of ZTK?
[04:57] <lifeless> wgrant: pretty much
[04:57] <wgrant> lifeless: And turn what was previously an innocent little piece of code into a horrid Zope egg?
[04:58] <lifeless> wgrant: zservertracereport is used to pull out stuff from the log files, and it pulls in ZOMG
[04:58] <lifeless> diminishing returns to avoid that.
[04:58] <wgrant> lifeless: Right
[04:58] <wgrant> That probably means we shouldn't use zservertracereport to pull out stuff from the log files :)
[04:58] <lifeless> but I didn't migrate anything else, so most folk can just ignore it.
[04:58] <wgrant> Since if we do then it won't be useful to anyone else.
[04:58] <lifeless> its no less useful to anyone.
[04:59] <wgrant> lifeless: Hmm?
[04:59] <StevenK>     ImportError: No module named testbrowser
[04:59] <StevenK> :-(
[04:59] <wgrant> lifeless: You're adding an insane amount of bloat that will probably be removed the first time someone touches it
[04:59] <wgrant> lifeless: Since I doubt $person wants to use it for Zope stuff
[05:00] <lifeless> wgrant: they're going to make it more pluggable
[05:00] <lifeless> we still need it for our logs.
[05:00] <lifeless> I don't know what your point is.
[05:00] <wgrant> My point is that lp-dev-utils is presently sane and usable.
[05:01] <lifeless> And its no less so.
[05:01] <wgrant> And doesn't have this bootstrap.py lets-copy-it-everywhere-because-screw-good-ideas madness
[05:01] <lifeless> All the existing scripts have exactly the same overheads they had before.
[05:03] <wgrant> It looks sensible, apart from the code and build infrastructure being trainwrecks.
[05:03] <wgrant> So OK, I guess.
[05:04] <lifeless> the existing code is the existing code; I copied in our custom option parser as a stopgap.
[05:04] <lifeless> The build infrastructure is no worse than what we use elsewhere, which for all its flaws has the massive advantage of actually working.
[05:04] <lifeless> wgrant: do I get a vote on the MP from you ?
[05:05] <wgrant> And the massive disadvantage of having all the vileness of Python upstream's distribution attitude combined with the vileness of Zope's.
[05:05] <wgrant> Sure
[05:05] <wgrant> But I would like to register my extreme distaste :)
[05:06] <lifeless> Sure, I feel the same way; but can't affort to spit the dummy - we'd end up having to write a stupidly large stack.
[05:06] <lifeless> starting with the way packages are imported from disk and working out from there.
[05:06] <wgrant> Right.
[05:06] <wgrant> But I was hoping to sort of keep the infection contained.
[05:07] <lifeless> it is contained, it doesn't affect php or ruby.
[05:07] <wgrant> lp-dev-utils is one of the last bastions of sanity.
[05:07] <wgrant> Ruby has their own mess
[05:07] <wgrant> And PHP is their own mess
[05:09] <StevenK> % bzr di versions.cfg | grep '^\+\w'
[05:09] <StevenK> +mechanize = 0.2.5
[05:09] <StevenK> +zope.app.testing = 3.10.0
[05:09] <StevenK> +zope.testbrowser = 4.0.2
[05:09] <StevenK> FEAR
[05:09] <wgrant> StevenK: What have you done to who and why?
[05:13] <StevenK> wgrant: http://pastebin.ubuntu.com/1137400/
[05:15] <wgrant> StevenK: There's a nuclear winter in our future.
[05:15] <StevenK> wgrant: That good?
[05:15] <wgrant> So much fallout.
[05:16] <StevenK> 'make' works, so WCPGW, right?
[05:16] <wgrant> Shipit!
[05:16] <StevenK> Haha
[05:16] <StevenK> HAHAHAHA
[05:16] <wgrant> Is that an evil mad nuclear physicist cackle?
[05:16] <StevenK> Yes, at your ShipIt reference.
[05:17] <StevenK> I was going to toss it at ec2 and sob like wallyworld_ and propose if ec2 doesn't send hate mail.
[05:17] <wgrant> Sounds good
[05:17] <wgrant> But the big zope.app.testing bump is a bit scary
[05:18] <StevenK> Although I'm still trying to get the last reference of bug=98437 out
[05:33] <lifeless> wgrant: or StevenK: I suck, I haven't ec2 enabled myself again yet. Could you land https://code.launchpad.net/~lifeless/launchpad/ppr-move/+merge/118873 ?
[05:33] <lifeless> per favor
[05:34] <StevenK> Fail.
[05:42] <wgrant> Hm
[05:45] <lifeless> StevenK: is that 'sure thing' ?
[05:46] <StevenK> It is not.
[05:47] <StevenK> ec2: ERROR: Branch doesn't have linked bugs and doesn't have no-qa option set. Use --no-qa, or link the related bugs to the branch.
[05:47] <StevenK> lifeless: ^ no-qa is fine?
[05:48] <lifeless> StevenK: yeah
[06:06] <lifeless> stub: hey; can we do a catchup @ uhm, 2h from now?
[06:07] <stub> lifeless: ok
[06:08] <lifeless> cool,t hanks
[07:40] <wgrant> wallyworld_: How do I see the bug title?
[07:41] <wallyworld_> ECONTEXT
[07:41] <wgrant> If it's ellipsised in the only place it's displayed, how do I see it?
[07:41] <wallyworld_> if it's too long then too bad
[07:41] <wallyworld_> or words to that effect
[07:42] <wgrant> But the font is huge and you can fit like nothing in one line
[07:42] <wgrant> In terms of bug title
[07:42] <wgrant> For projects it might be reasonable.
[07:42] <wallyworld_> the bugtitle issue was the one mentioned as needing fixing. perhaps a longer allowed title is required
[07:43] <wallyworld_> maybe we allow 2 lines or something
[07:50] <adeuring> good morning
[07:56] <mgz> okay, some let's play writing some debbugs tests
[07:56] <StevenK> mgz: Hahahahaha
[09:09] <dpm> Hi launchpadders. Right now source packages from the extras.ubuntu.com archives are not available in Launchpad through https://launchpad.net/ubuntu/+source/<package> - could someone tell me (roughly) what would be needed to get source packages from extras show up in Launchpad?
[09:15] <cjwatson> From Launchpad's point of view, extras.ubuntu.com is just another PPA.
[09:16] <cjwatson> So they do show up there, but only under the "untrusted archives" expander (e.g. https://launchpad.net/ubuntu/+source/alg3py).
[09:20] <wgrant> Hm
[09:20] <wgrant> Why should they show up under Ubuntu?
[09:20] <wgrant> They're not part of or maintained by Ubuntu.
[09:32] <dpm> that's a good point. I was thinking in terms of were to report bugs, but hadn't considered the fact that they're not really part of Ubuntu
[09:39] <dpm> wgrant, but you can still report bugs against e.g. https://bugs.launchpad.net/ubuntu/+source/alg3py right? So what do you think could be the best approach to report bugs against extras applications in LP?
[09:41] <wgrant> dpm: Hm, I thought we used to hide the link. It nowadays seems to let you into the form, but won't let you submit.
[09:41] <wgrant> So no, you can't actually file bugs.
[09:41] <wgrant> It just tempts you to do it
[09:42] <wgrant> I'm not sure what the best solution is
[09:42] <wgrant> But forcing them under Ubuntu like partner is probably not it.
[09:42] <mgz> where do the debbugs things live on disk? could do with looking at some real data to see if my tests are valid
[09:42] <mgz> config has /srv/bugs-mirror.debian.org/ but don't know what server, or the process that creates the files
[09:44] <dpm> ok, thanks wgrant
[09:46] <cjwatson> mgz: http://www.debian.org/Bugs/Access "Accessing the raw bug data"
[09:47] <mgz> ah, so we have a full mirror rsynced?
[09:47] <mgz> do you know where that lives?
[09:47] <cjwatson> No
[09:48] <cjwatson> But it's easy enough to rsync at least a fragment of it for yourself
[09:48] <mgz> right, I just need to try and get a reasonable fragment without killing this http connection :)
[09:49] <mgz> (specifically I want some bugs with non-ascii characters in headers, just to check)
[09:49] <cjwatson> I suspect that these days any 1% of the active spool would do, so pick a subdirectory ...
[09:49] <wgrant> It used to be on macquarie then synced to loganberry, but the former copy moved recently, AIUI
[09:58] <lifeless> mgz: the network diagram ops have lists the machine name I believe.
[09:59] <mgz> loganberry works for me
[10:11] <wgrant> lifeless: Have you fixed the crontab for the PPR move?
[10:12] <lifeless> wgrant: no, I didn't think it was on autodeploy
[10:12] <lifeless> wgrant: fairly sure its manually updated.
[10:14] <wgrant> Ah, probably true,.
[10:16] <lifeless> so I was going to completely ignore it and wait for screams, if any.
[12:48] <jam> anyone have advice for https://answers.launchpad.net/launchpad/+question/205338
[12:49] <jam> I can see that https://launchpad.net/ubuntu/+source/openconnect is definitely not the same project as https://launchpad.net/openconnect
[12:49] <jam> However, I don't see the former as being imported anywhere.
[12:49] <jam> i'm also hesitant to rename an existing project and import something new in its place.
[12:49] <jam> Thoughts?
[12:54] <mgz> jam: you have a reasonable fix now, from the question?
[12:55] <jam> mgz: I think so
[13:01] <mgz> seems unexpected success in the lp test suite doesn't count as a failure?
[13:05] <mgz> gmb: what did you do previously to make the launchpad test runner understand other test results?
[13:06] <gmb> mgz, I'm sprinting today so I can't give you a good answer right now... Is this under Python 2.6 or 2.7?
[13:06] <mgz> er, I'm testing in precise, so 2.7, but that's a good point
[13:07] <wgrant> mgz: LP's test suite doesn't have any expected failures.
[13:08] <wgrant> How're you trying it?
[13:08] <mgz> ah, so I shouldn't use that feature at all...
[13:08] <mgz> it derives from testtools so appears to work, but the zope runner is ignorant
[13:09] <wgrant> We make tests pass instead :)
[13:10] <mgz> I'm (sometimes) in the habit of committing tests, then fixing the bug and flipping the expectedFailure clause
[13:10] <mgz> but I can just not do that.
[13:12] <mgz> also have some assertions that are not currently unused code that I guess can just be deleted, like
[13:12] <mgz> +        name, email = tracker.getBugReporter("1")
[13:12] <mgz> +        self.expectFailure("No decoding on headers done",
[13:12] <mgz> +            self.assertThat, name, Not(Equals("=?UTF-8?Q?Jes=C3=BAs?=")))
[13:13] <mgz> +        self.assertThat((name, email),
[13:13] <mgz> +            Equals((u"Jes\xfas", "jesus@example.com")))
[13:39] <cgoldberg> morning... I am having a problem bootstrapping lp-dev-utils.  "pkg_resources.DistributionNotFound: zc.buildout==1.5.2" (I have python-zc.buildout 1.52 installed globally) .... stack trace of make output:  http://paste.ubuntu.com/1137808/
[13:39] <cgoldberg> anyone have an idea?
[13:48] <jam> I'm trying to go to: https://launchpad.net/projects/+review-licenses but now it is generally timing out
[13:48] <jam> I think it succeeded 1 time in about 8
[13:48] <jam> (It worked a bit ago, but then I reviewed a bunch of projects, so maybe there is a data-bug where one of the new projects to review is causing the timeout?)
[14:36] <deryck> cgoldberg, hey.  Does a plain `make` not work?  I expect it's something to do with lp-dev-utils expectations about there being a download-cache.
[14:38] <cgoldberg> deryck, plain `make` does nothing (Nothing to be done for `all'.)
[14:38] <deryck> hmmm
[14:39] <cgoldberg> `make bin/buildout` and calling bootstrap.py directly  gives same error as my paste
[14:39] <cgoldberg> i've tried with, and without zc.buildout installed system-wide
[14:39] <deryck> cgoldberg, ok, looking at my copy now.....
[14:39] <cgoldberg> deryck, kk thanks
[14:40] <cgoldberg> i've also tried running bootstrap.py with -t and -d options
[14:43] <deryck> cgoldberg, what are you trying to do?  I didn't even realize we needed a Makefile in there.  It used to just be a collection of scripts.
[14:44] <cgoldberg> deryck, right... so lifeless moved pageperformancereport (prr) into there from lp:launchpad.  i'm trying to run the tests:  test_pageperformancereport.py
[14:44] <cgoldberg> deryck, the README is updated... look at the last part of it
[14:45] <cgoldberg> i'm not sure if he added the bootstrap/make stuff or that was there already.. but seems it's needed
[14:46] <deryck> cgoldberg, ah.  reading the makefile, I suspect you need `make download-cache && make eggs` before `make bin/buildout`.
[14:46] <cgoldberg> deryck, i'll try
[14:47] <deryck> ok
[14:47] <cgoldberg> deryck, "make: `download-cache' is up to date."  ... same for eggs
[14:48] <deryck> cgoldberg, do you have a download-cache directory in the tree?
[14:48] <cgoldberg> deryck, yup
[14:49] <deryck> cgoldberg, hmmm, I'm not sure then.  Maybe check with lifeless when he is around.
[14:49] <cgoldberg> with a ton of tarballs/zips under /dist
[14:49] <cgoldberg> deryck, yea.. fraid i'll have to.. was hoping to get through this before he arrives later
[14:49] <deryck> cgoldberg, I would think if you had buildout in the download cache, or system wide, either one.  it should work.
[14:50] <cgoldberg> deryck, me too :)
[14:50] <deryck> cgoldberg, assuming the version is indeed 1.5.2
[14:50] <cgoldberg> right.. which it is
[14:50] <cgoldberg> deryck,  well.. thanks for looking  anyway!
[14:51] <deryck> cgoldberg, np!  sorry I couldn't help.
[14:53] <james_w> cgoldberg, either remove the global installation, or run the bootstrap in a --no-site-packages virtualenv (which can then be deleted I think)
[14:54] <james_w> buildout bootstrap fails if there is a system-wide install of the same version as the desired one
[14:59] <cgoldberg> james_w, ahh..i tried removing my system-wide buildout.. didn't help.  I'll try in a virtualenv
[15:02] <deryck> adeuring, let's use the standup hangout.
[16:03] <mgz> ocr: please take a look at  <https://code.launchpad.net/~gz/launchpad/format_version_3_debbugs_1029294/+merge/118989>
[20:32] <deryck> rick_h_, no hurry, but let's use the standup hangout again when you're ready
[20:32] <rick_h_> ok, jumping in
[21:10] <lifeless> sinzui: o/
[21:10] <lifeless> deryck: hi
[21:10] <sinzui> both of you just got mail
[21:10] <lifeless> deryck: we were going to do a call this morning, but neither of us put it into google calendar.
[21:10] <deryck> lifeless, dang, dude.  I completely forgot.  *sigh*
[21:11] <deryck> lifeless, I need to go pick up the dog too.
[21:11] <deryck> lifeless, shall we calendar something for my monday afternoon, your Tuesday morning?
[21:12] <lifeless> sure
[21:13] <deryck> thanks, really sorry about dropping that again.
[21:13] <deryck> lifeless, I'm not sure what time for me works for you, so feel free to calendar me for a time that works for you.
[21:13] <deryck> i'll be around whenever then.
[21:13] <deryck> sinzui, thanks for the mail.  I'll need some time tonight to get it all in my head, but it's nice to have a good list like that.
[21:14] <sinzui> deryck: I cannot say that is in my head. That might be a fiction about what was done
[21:15] <deryck> well, I don't mean it will stay in my head. :)
[21:15] <deryck> Get my head around it, might be a better way to say it.
[21:17] <Ergo^> gary_poster, ping
[21:17] <gary_poster> Hey Ergo^
[21:20] <lifeless> sinzui: your 12 step program is short a step
[21:21] <sinzui> So is my head
[21:23] <lifeless> :>
[21:24] <jcsackett> wgrant: online?
[21:25] <lifeless> jcsackett: 0724 for him.
[21:25]  * lifeless expresses doubt about onlineness
[21:25] <jcsackett> lifeless: fair. we do standup in 30 min, wondered if he might be online early.
[21:26] <lifeless> oh definitely worth checking
[21:26] <lifeless> never know your luck in the big penal colony
[21:26]  * jcsackett laughs
[21:27] <jcsackett> well, without wgrant, sinzui. i am *finally* able to focus on that banner branch today and i think discussions from last night are wrong.
[21:28] <jcsackett> sinzui: IPrivacy, in this instance at least, would only be used for display of the banner...which is a very different thing from who all can *see* it.
[21:28] <sinzui> yes.
[21:28] <jcsackett> and the rules we agreed to adapt are all about seeing. i think the archive being private is enough to say show the banner.
[21:30] <sinzui> jcsackett: it is a start certainly. But is two people look at the same build. One gets a 403, so ask the other to look and he sees it. the page might as well show the privacy banner so that user to can tell person one that is the case
[21:31] <sinzui> I think the ambiguity of the bug is that user know that not everyone can see the page and have a reason in their head that something might be private...
[21:31] <sinzui> and per you decision, the archive is going to leap to the user's mind
[21:32] <jcsackett> what i'm saying is that i think that's the case. the archive being private is the first check for 'View'. so if it's private, the build is private. so someone else goes to look at it and gets in b/c they match another rule. but they'll see it's private.
[21:32] <jcsackett> e.g. I don't think there's a reason you get a 403 looking for it when the archive is public.
[21:36] <sinzui> okay
[21:37] <sinzui> I think that fixes jml's concern
[21:37] <jcsackett> ok.
[22:07] <wgrant> jcsackett: The build archive being private is required, but not sufficient.
[22:08] <wgrant> I can copy the source+binaries to the Ubuntu primary archive
[22:08] <wgrant> Then it is no longer private.
[22:08] <lifeless> rick_h_: http://paste.ubuntu.com/1138589/ + http://paste.ubuntu.com/1138605/ - a WIP
[22:09] <lifeless> rick_h_: imbrandon is hacking the js bits together
[22:11] <jcsackett> wgrant: but in terms of viewing the build, shouldn't we still display the banner? b/c there is still private info on the build (e.g. the existence of the archive), right?
[22:12] <wgrant> jcsackett: But the build is publicly available, therefore the existence of the archive is disclosed.
[23:00] <StevenK> wallyworld_: My X201 is 1280x800
[23:00] <wallyworld_> wow, that's sad
[23:01] <wallyworld_> in 2000 i would expect that, not 2012
[23:01] <StevenK> wallyworld_: It also weighs 1.4kg and has 8 hours battery life?
[23:01] <wallyworld_> mine weighs about the same, battery is only 4h
[23:02] <wallyworld_> but i hardly ever run on battery
[23:40] <rick_h_> lifeless: why do the iframe if it's a GET request anyway?
[23:41] <rick_h_> and are we thinking more than one per page? because the instances can clobber in this plain object fashion vs creating a new instance of an oops
[23:41] <rick_h_> but I guess there's not much to change atm since things like action/etc aren't populated
[23:42] <lifeless> rick_h_: its existing code imbrandon is using
[23:42] <rick_h_> ah gotcha
[23:47] <StevenK> wgrant: An awful lot of the failures are NoReferrerError: No value for REFERER header
[23:47] <lifeless> rick_h_: #juju is where we are talking about this
[23:47] <wgrant> StevenK: Ah
[23:47] <wgrant> StevenK: I guess people might be posting forms directly
[23:47] <StevenK> Right
[23:47] <wgrant> StevenK: Rather than properly submitting them
[23:48] <wgrant> In which case you'll need to either properly submit them or forge a referer
[23:48] <StevenK> wgrant: browser.submit() , isn't it?
[23:48] <wgrant> Right
[23:48] <wgrant> Maybe
[23:48] <wgrant> It may be on the form
[23:48] <wgrant> Can't remember.
[23:49] <StevenK> admin_browser.getControl('Delete').click()
[23:49] <StevenK> That's wrong?
[23:50] <wgrant> That should work.
[23:52] <StevenK> wgrant: http://pastebin.ubuntu.com/1138729/
[23:52] <wgrant> StevenK: Do other things work?
[23:53] <wgrant> Perhaps the new testbrowser doesn't send a referer at all


[00:17] <kees> well that was fun. installed precise on top of a machine that had lucid on it. alternative install decided it was an EFI machine (BIOS yes, drive layout no), and installed grub-efi which happily ignored the old grub on the sda, which became highly confused about drives moving.
[00:17] <kees> seems like partman needs to learn about GPT and offer that on EFI machines.
[00:18] <cjwatson> Err
[00:18] <cjwatson> partman learned about GPT years ago and it's the EFI default
[00:19] <cjwatson> This is a bug, not a missing feature
[00:19] <cjwatson> But
[00:19] <cjwatson> If you already have a partition table, it isn't sane to offer a different partition table type
[00:19] <cjwatson> Rewriting the partition table would be very scary and very likely to break whatever's already on there
[00:20] <cjwatson> Dual-booting BIOS and UEFI installs on the same disk is not likely to work desperately well in general, really; you lose either way round
[00:21] <cjwatson> A BIOS boot loader can't boot a UEFI install, so leaving the existing GRUB on there wasn't an option, and as you say there are confusion issues with using a UEFI boot loader
[00:21] <cjwatson> Probably the right thing to do was to boot the installer in legacy mode (there's generally an option for this in the firmware boot menu) and then it would have proceeded in BIOS mode
[00:22] <cjwatson> If the installer is booted using UEFI, it assumes that it should install using UEFI too
[00:23] <cjwatson> Though if you weren't preserving the old partition table (it's not clear?), then perhaps we should zero out the old boot sector when doing a UEFI install
[00:23] <cjwatson> I dunno, doing that kind of thing scares me a bit
[00:24] <cjwatson> Maybe do it at the time the old partition table is wiped instead
[03:20] <pitti> Good morning
[03:24] <em> good morning
[05:44] <pitti> infinity, RAOF: I'd be grateful if you could process the postgresql-9.1 SRUs for bug 1055944
[05:44] <pitti> infinity, RAOF: standard microrelease exception, but the -9.1 update is rather urgent and people are nagging for it
[05:44] <RAOF> pitti: Sure.
[05:44] <pitti> I'll do the verification as soon as the packages are built in -proposed
[05:44] <pitti> RAOF: merci beaucoup
[05:45] <RAOF> Bitte
[06:01] <RAOF> pitti: Done.
[06:02] <pitti> RAOF: cheers! I uploaded the 8.4/8.3 updates as well, but they are a bit less urgent
[06:02] <RAOF> I might do them tomorrow on my regular processing day if infinity doesn't get to them first.
[06:03] <pitti> sounds fine
[06:31] <infinity> RAOF: Thanks for catching those, I was out all evening.
[06:32] <infinity> pitti: Many thanks for the fixed glib.
[06:51] <pitti> infinity: well, here's hoping it'll build at last..
[06:51] <pitti> I have no idea what changed on the arm builders that they suddenly became so slow/loaded/whatever
[06:52] <pitti> infinity: btw, if/when that builds, do you want them copied to quantal? there's no source changes compared to the one in quantal, just the arm ftbfs fix
[06:52] <pitti> infinity: but that would need coordination with image respins, of course
[06:53] <pitti> well, only source changes in tests, that is
[06:56] <dholbach> good morning
[06:56] <pitti> hey dholbach, how are you?
[06:57] <freyja_> can this https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1055766 bug just be deleted? It is a waste of everyone's time and immature. It's posted on /r/linux and will contribute to FUD. It's a waste of time and burden on the community.
[06:58] <dholbach> hey hey pitti - doing well, I'm almost over my cold :)
[06:58] <dholbach> how are you?
[06:58] <pitti> dholbach: je vais tres bien, merci :)
[06:58] <dholbach> excellent :)
[07:28] <bryceh> infinity (or another archive admin), mind bumping the nvidia packages from NEW?  https://launchpad.net/ubuntu/precise/+queue
[07:36] <bkerensa> bryceh: I did the fix you had for task
[07:38] <bryceh> bkerensa, awesome thanks.  Yes I did spot that today.
[07:38] <bkerensa> bryceh: do you think it will land quantal?
[07:38] <bryceh> bkerensa, one thing I noticed was that the fix was applied to source, rather than as a patch in debian/patches/, so I wanted to take a look at that.
[07:39] <bkerensa> k
[07:39] <bryceh> bkerensa, yes I am certain it will.  Even if it has to be SRU'd in post release, I'll help you make sure it happens.  :-)
[07:40] <bryceh> bkerensa, would you like to take a shot at adding the patch in debian/patches/ ?
[07:41] <bkerensa> hmm
[07:41] <bkerensa> I dont think I have done that before
[07:41] <bkerensa> let me go rtfm for a bit and have a try
[07:42] <bryceh> it looks like I already set up quilt for this package.  I think all you need to do is create a "debian/patches/<something>.patch" file, and then also add that filename to debian/patches/series and a changelog entry
[07:42] <bkerensa> hmm
[07:42] <bkerensa> ok
[07:42] <bkerensa> and revert the source back to what it was?
[07:42] <bryceh> yep
[07:42] <bkerensa> k
[07:42] <bryceh> bkerensa, cool, it's a good thing to learn to do.   If you get stuck or have questions just drop me a PM or email and I'll help.
[07:48] <Daviey> RAOF: hey, the precise unapproved SRU queue is looking pretty huge.. is iot being attacked?
[07:48] <Daviey> (The reason i noticed, is that we are being nagged for openvswitch which has been there since the 8th.)
[07:49] <bkerensa> bryceh: ok I made the changes I understand need to be made can you check and let me know if it looks sane or just comment needs fixing with suggestions
[07:49] <bkerensa> thx
[07:52] <bryceh> bkerensa, ok will do
[07:56] <bryceh> bkerensa, ok this looks good!  But a couple suggestions
[07:56] <bkerensa> bryceh: sure
[07:56] <bryceh> bkerensa, the patch should be named to mention what it's solving, not just a bug number since that can just be looked up easy enough
[07:57] <bkerensa> ok
[07:57] <bryceh> so in this case maybe let's see...
[07:57] <bryceh> only_stack_size_1.patch
[07:57] <bryceh> or whatever... something like that
[07:58] <bryceh> bkerensa, second, if the changelog make sure to answer three questions:  1.  Where did the  patch come from (e.g. upstream bug number or url), 2.  What does the patch do, and 3. What is the problem it fixes.
[07:58] <bkerensa> ok
[07:58] <bryceh> s/if the/in the/
[07:59] <bryceh> so 3 is "Fixes a crash when ...."
[07:59] <bryceh> 2 is something like "Check that the stack size is exactly 1 rather than just some value lower than 2" (or look at the upstream bug report if they give a better explanation)
[08:00] <bryceh> and 1 is just "Fixes upstream crash bug #xyz"
[08:01] <bryceh> as part of #1 I usually like to indicate if the patch was taken directly from upstream or if I've had to modify it in some fashion to get it to apply.  But that's probably irrelevant here.
[08:02] <bkerensa> bryceh: how do we list bug #'s for projects like task?
[08:04] <bkerensa> bryceh: "Cherrypick patch from upstream bug 1048 to fix a segfault when modify"
[08:06] <bryceh> bkerensa, "upstream bug 1048" would be sufficient.  Anyone looking at the package could be expected to figure out where their bug tracker is.  But if you want to be super clear you could just paste the full URL.
[08:07] <bkerensa> bryceh: ok and do I need to still mention our bug?
[08:08] <bryceh> bkerensa, yep always.  Just like you did, (LP: #1032861) appended to the description is perfect
[08:09] <bryceh> btw you don't have to mention that you updated the series
[08:12] <bkerensa> bryceh: ok all done
[08:14] <bryceh> bkerensa, good work!  Oh one last thing.  In this case instead of "* debian/patches:" can you make the changelog read "* debian/patches/only_stack_size_1.patch:"
[08:15] <bkerensa> surely
[08:15] <bryceh> it's nitpicky in this case since there's just the one patch, but in packages with a lot of patches it is helpful since then other devs can search for the patch name to see when it got added and why
[08:16] <bkerensa> bryceh: done and pushed
[08:17] <bryceh> bkerensa, excellent, looks good.
[08:30] <bryceh> bkerensa, upload sponsored for quantal. thanks again!
[08:30] <bkerensa> bryceh: :) thx
[09:24] <ev> mpt_: well, we could have done worse: http://people.canonical.com/~evand/tmp/Screen%20Shot%202012-09-25%20at%2010.21.16.png
[09:25] <seb128> ev, hey, did you see my ping yesterday?
[09:25] <ev> seb128: no - I guess that was past my irc bouncer scrollback buffer
[09:25] <ev> what's up?
[09:25] <ev> (I was on holiday friday and monday)
[09:26] <seb128> ev, is there known issue with e.u.c? I'm wondering why bug #1053670 is not showing up on the daily or monthly view seeing the list of duplicates from the retracers, whoopsie should at least have the same number and that should be enough to make it displayed on the main page
[09:31] <ev> seb128: it may have failed to retrace on the daisy retracers (but not the crash-digger ones): https://bugs.launchpad.net/daisy/+bug/1044418
[09:32] <ev> I'll try hunt it down on errors.u.c in a bit
[09:32] <ev> thanks for bringing that to my attention
[09:33] <seb128> ev, thanks
[10:02] <dpm> xnox, are you now maintaining ubiquity? And if so, could you look at bug 1040438 if you've got some time? thanks!
[10:05] <xnox> dpm: i'm not the only maintainer =) there are a few in the installer team taking. Well I saw the bug mail & there are a couple of other l10n issues, I may look at them in bulk sometime.
[10:06] <dpm> xnox, thanks. Yeah, I just wanted to know the best person to poke. I used to ping Evan, but I wasn't sure if he still maintained it
[10:07] <xnox> dpm: the best way is to simply add a tag 'rls-q-incoming'
[10:07] <dpm> xnox, cool, thanks.
[10:08] <xnox> and then appropriate teams will triange the bug and either nominate it for a release, assign to correct 'maintainer' etc.
[10:08] <xnox> dpm: that tag works on any supported package ;-)
[10:08] <xnox> not just ubiquity.
[10:10] <cjwatson> it's not a guarantee; we do elect not to commit to fixing some rls-q-incoming bugs
[10:10] <cjwatson> if the number of people using it rises, I expect we will commit to a lower percentage :)
[10:20] <pitti> ev: hey Evan, how are you?
[10:20] <pitti> ev: If you have a minute, I'd appreciate your opinion in bug 1039220 before I merge that branch
[10:20] <ev> hi pitti! I'm excellent, thanks.
[10:20] <ev> how are you?
[10:20] <ev> will do!
[10:21] <pitti> ev: I'm great, thanks! (when I'm not headdesking on glib FTBFS, that is :) )
[10:22] <ev> :)
[10:56] <doko> pitti, please see the pkgbinarymangler ftbfs
[10:59] <doko> directhex, gnome related ftbfs: libgtk2-perl, (main), gcompris, glade-3, gestreamermm, launchpad-integration, libgnomecups (package sets)
[11:00] <doko> forgot gtk2-engines
[11:01] <doko> tkamppeter, please have a look at the hplip ftbfs, https://launchpadlibrarian.net/117005844/buildlog_ubuntu-quantal-i386.hplip_3.12.6-3ubuntu1_FAILEDTOBUILD.txt.gz
[11:04] <directhex> doko, hm?
[11:04] <doko> seb128, please could you add the ubuntu-toolchain-r ppa as a dep to the webkit ppa, and give back webkit?
[11:04] <seb128> doko, can do
[11:05] <doko> directhex, should have been didrocks
[11:05] <seb128> didrocks, doko: I will look at those desktop ftfbses, didrocks is already under heavy pinging and todo ;-)
[11:05] <didrocks> doko: right, so you are quite lucky to not be under this load
[11:06] <doko> seb128, and any desktopish ftbfs ;)
[11:06] <seb128> doko, will do
[11:06] <davmor2> Hey guys I see a launcher for amazon after todays updates however if I click on it, it opens FF and then removes the launcher
[11:07] <doko> pitti: ubuntu-defaults-builder ftbfs
[11:08] <Laney> doko: the make patch is not needed?
[11:08] <seb128> Laney, I guess it is, binutils should fix the ar issue, not the argument list one
[11:09] <Laney> that's what I think
[11:09] <pitti> doko: yes, will do
[11:10] <doko> Laney, I didn't see it in the ppa
[11:12] <Laney> doko: https://launchpad.net/~ubuntu-desktop/+archive/ppa/+packages
[11:13] <Laney> doko: and do you mean ubuntu-toolchain-r/test, staging or ppa?
[11:14] <doko> Laney, ppa
[11:15] <Laney> I'll try without make first
[11:17] <Laney> doko: https://launchpad.net/~laney/+archive/webkit/+build/3853350
[11:20] <doko> looks like we were not good with merging this cycle ...
[11:20] <cjwatson> doko: I'm looking at klibc
[11:34] <pitti> doko: u-defaults-builder test failure points out a config file format change in unity, so that's great to catch \o/
[11:39] <doko> Laney, pitti: libproxy looks like your pet
[11:39] <doko> ftbfs ...
[11:39]  * pitti bounces to Laney
[11:40] <Laney> ta
[11:40] <Laney> probably just a missing include
[11:42] <pitti> doko: defaults-builder FTBFS fix uploaded to unapproved
[11:46] <pitti> I cannot reproduce the pkgbinarymangler FTBFS here, all tests work; trying in my PPA; looks like pkgbinarymangler is installed in the rebuild test environment, but in some special way
[11:48] <doko> it shouldn't be anything special, nothing preseeded
[11:49] <pitti> oh hang on
[11:49] <pitti> ok, lunch, then fix :)
[11:55]  * doko is staring at the ppp ftbfs
[11:59] <Laney> libproxy uploaded
[12:16] <alexbligh1> Does this quantal->precise backport request have a snowball's chance in hell of succeeding? (allows Precise to mount Windows 2012 server exported SMB drives). Not trying to persuade anyone, just get an idea of the height of the hurdle for backport requests.
[12:16] <alexbligh1> https://bugs.launchpad.net/precise-backports/+bug/1056137
[12:28] <tumbleweed> alexbligh1: it sounds like a big enough issue that it should be dealt with by an SRU rather than a backport (backports don't exist to fix bugs)
[12:29] <tumbleweed> but I have no idea how big the patches to bring win 2012 support to the version in precise would be
[12:29] <tumbleweed> in general, for a backport to have a snowball's chance in hell of succeeding: you should do all the testing requestbackport asks for
[12:38] <alexbligh1> tumbleweed, the issue (both with an SRU and the testing) is that updating the samba source package means the SMB /server/ gets updated too. I have no idea how to test that fully as I haven't got any Windows clients, printers, blah blah blah. I've not much idea what has changed server side. All I really want to update is the client, so Precise can mount Windows 2012 servers. Windows 2012 clients will (I believe) mount older servers an
[12:38] <alexbligh1> ywhere.
[12:38] <alexbligh1> s/anywhere/anyway/
[12:39] <alexbligh1> I'd be nervous about changing the default *server* (by upgrading samba). If it were possible to break out just the library from Samba, that would I think be far safer.
[12:40] <tumbleweed> alexbligh1: we apply minimal patches in SRUs - so it would only be SRUable if there was something fairly minimal that could be applied
[12:40] <tumbleweed> anyway, chat to the #ubuntu-server people
[12:45] <tkamppeter> doko, I am looking currently into that. The starnge thing which happemns here is that formaerly HPLIP built perfectly and suddenly, all "->" raises the error "dereferencing pointer to incomplete type".
[12:46] <tkamppeter> doko, do you have any idea what that means? The CUPS API did not change with respect to these data structures, and HPLIP built some weeks ago.
[12:47] <doko> tkamppeter, I assume some reorganization did change. glib, gtk?
[12:47] <doko> header reorg, I mean
[12:48] <alexbligh1> tumbleweed, thanks
[12:48] <tkamppeter> doko, the data structures are defined in CUPS but they did not change, they still match. Strange is also that EVERY "->" raises the error.
[12:49] <tkamppeter> cupsext
[12:49] <cjwatson> tkamppeter: That indicates that at the point when the compiler encounters the thing before the ->, it doesn't have a full definition of its type
[12:49] <cjwatson> i.e. usually missing header or similar
[12:53] <tkamppeter> cjwatson, earlier in the code there is a line "ipp_t *request = NULL;", which clearly assigns the correct type to the variable "request", and assuming that the header would be missing, the compiler should already complain at "ipp_t" which it does not do.
[12:59] <doko> tkamppeter, but at this point, it doesn't need to know the struct
[13:31] <dholbach> I'm doing an ubuntu development hangout in ~30m - would anyone like to co-host it with me? :)
[13:33] <cjwatson> tkamppeter: not true
[13:34] <cjwatson> tkamppeter: the compiler has enough information for "ipp_t *request = NULL;", because the size of a pointer is the same no matter what it points to.
[13:34] <cjwatson> tkamppeter: that doesn't mean it has enough information to dereference the point
[13:34] <cjwatson> *pointer
[13:36] <stgraber> dpm: a broken html file was preventing the generation of updated pot templates...
[13:36] <stgraber> dpm: I'll do a manual import of the new .pot in launchpad for now and will do a full translation update before release.
[13:37] <dpm> stgraber, excellent. Could you just ping me when you've done the manual import, so that I can give a heads up to translators?
[13:39] <tkamppeter> cjwatson, thank you very much. I have found the cause of the problem now, in the CUPS *.h files new conditionals to hide the private data structure from non-CUPS builds were added. Now I succeeded to rebuild the package by overriding the conditionals via "-D..." in CFLAGS.
[13:40] <stgraber> dpm: done
[13:40] <stgraber> dpm: LP correctly reports the "Welcome to Ubuntu 12.10" string as needs translation now
[13:41] <cjwatson> tkamppeter: Right.  Though be careful as that kind of thing often indicates that the relevant structures are now considered private and won't be ABI-stable
[13:41] <sconklin_> @pilot in
[13:42] <cjwatson> Sometimes it goes along with better alternative ways to do the same things (e.g. accessor functions)
[13:42] <cjwatson> Not that I know anything about CUPS, this is just standard practice for libraries
[13:44] <diwic> doko, I believe I have fixed the quantal ftbfs for libffado (by cherrypicking a patch from upstream), where do I put it so that someone finds and uploads it?
[13:44] <dpm> stgraber, excellent, thanks!
[13:44] <doko> diwic, please open a bug report
[13:45] <doko> or just put the diff.gz and .dsc somewhere where I can fetch it
[13:45] <diwic> doko, ok, will ping you once I have a debdiff ready
[13:46] <doko> can't explain the noweb build failure on armhf, giving it back
[13:51] <tkamppeter> cjwatson, I have reported the problem upstream to the HPLIP guys now: bug 1056214. Feel free to comment.
[13:54] <Laney> Subject: [Build #3853350] amd64 build of webkit 1.9.91-0ubuntu1~build1 in ubuntu quantal RELEASE (laney-webkit PPA) :(
[13:54] <tkamppeter> doko, cjwatson, fixed HPLIP uploaded.
[13:55] <Laney> ok, so I'll take the new make-dfsg now
[13:56] <ev> mpt: http://poppy-dev.local/ - is that dot pattern what you're after, or should we go a blank background or something else?
[13:57] <doko> Laney, is the new webkit a requirement for q?
[13:57] <Laney> we can't really stay on a dev release
[13:58] <Laney> https://bugs.webkit.org/show_bug.cgi?id=94435 if that gets fixed we'll be ok
[14:01] <diwic> doko, ok, bug 1056193, debdiff in comment 4, diff.gz/.dsc in 5 and 6
[14:05] <cjwatson> mvo: Do you know whether there's a sensible way in python-apt to reset the entirety of apt_pkg.config to what you'd get from apt_pkg.init_config()?
[14:05] <cjwatson> I'm trying to make sure tests I'm writing are correctly isolated, and would like to avoid having to use a subprocess if possible.
[14:06] <cjwatson> Taking a copy of the whole apt_pkg.config object doesn't work, presumably because the actual configuration lives in libapt_pkg itself; apt_pkg.init_config() uses CndSet under the covers so ignores anything already set; and there's no obvious "clear everything" method
[14:06] <cjwatson> I feel I must be missing something
[14:06] <mvo> cjwatson: there is none right now, but that should be (re)added really, I'm in a meeting right now, but I'm happy to talk about it in a bit
[14:07] <cjwatson> OK.  These are Launchpad tests so they have to run on lucid (at least at the moment), so I'll have to come up with a workaround that doesn't involve changing {python-,}apt.  Thanks.
[14:10] <cjwatson> Maybe apt_pkg.config.clear("APT"); apt_pkg.config.clear("Dir"); apt_pkg.init_config() would be sufficient in practice
[14:11] <cjwatson> A nice interface might involve making apt_pkg.config.clear() work ...
[14:12] <mvo> cjwatson: yeah, I think that is the key, adding libapt clear() and exposing that to python-apt
[14:15] <mvo> cjwatson: let me try to build something for you, will be a bit slow due to the call but
[14:17] <mpt> ev, pretty good. :-) The values on the axis need tick marks, and the dots should subdivide them sensibly. 7 days for X is good, but 0.00333 for Y is a bit weird.
[14:18] <mvo> cjwatson: does http://paste.ubuntu.com/1226696/ look reasonable?
[14:18] <ev> mpt: yes - I'm working on lining them up, but I wanted to make sure the dot pattern worked as an idea first
[14:19] <mpt> ok
[14:19] <ev> might work backwards and figure out what the tick interval should be to get the same spacing between the dots on the x and y axis
[14:25] <seb128> ev, did you figure out why the nautilus issue is not showing up on e.u.c?
[14:25] <ev> still working onit
[14:25] <ev> on it
[14:26] <seb128> ok
[14:29] <cjwatson> mvo: oh, yeah, duh, that would work wouldn't it
[14:29] <cjwatson> Slightly inclined to take a copy of .keys() first to defend against problems with modifying something while iterating over it
[14:30] <mvo> cjwatson: yeah, good idea, it seems to be ok, but +1 for safety
[14:31]  * cjwatson sticks that in tearDown() then, thanks a lot
[14:32] <doko> Sweetsha1k, seb128: libreoffice b-d's on libvigraimpex-dev, however there is no libreoffice binary depending on the library. what's the reason for this b-d? it's the last user of vigra in main, would like to demote it
[14:42] <Sweetsha1k> doko: vigra is mostly a header-only lib, so we are using the headers only (like most of e.g. boost)
[14:43] <Sweetsha1k> doko: thus build time only, nothing needed at runtime.
[14:43] <doko> Sweetsha1k, which cannot be avoided?
[14:45] <Sweetsha1k> doko: As you say its the only user left in main, I can use the interal LibreOffice copy of vigra -- shouldnt be much of an change. Its likely different for debian because they have no main/universe split and thus have more users for vigra anyway.
[14:46] <bdmurray> ev: could you look comment on bug 1039220 again?  I think we should not send bugs with an unreportable reason to the crash database at this point in time.
[14:47] <ev> bdmurray: yeah, pitti asked me this morning
[14:47] <ev> it's on the list :)
[14:47] <bdmurray> ev: ah, okay then!
[14:55] <mitya57> didrocks/Mirv: will there be one more libunity upload before the release?
[14:59] <Mirv> mitya57: yes, and the changes should be gotten in this week
[15:00] <mitya57> Mirv: ah thanks. So I want you to merge lp:~mitya57/ubuntu/quantal/libunity/lp1055019 now :)
[15:00] <needhelp1> Hello
[15:01] <needhelp1> I wanted to share the link to the Ubuntu Beta Users Survey, http://nathanheafner.com/home/2012/09/11/ubuntu-beta-users-survey/   . This survey ends tomorrow.
[15:03] <sladen> needhelp1: were you the person I helped before?
[15:03] <needhelp1> sladen: im not sure
[15:03] <sladen> needhelp1: on 12 September 2012 I spent a large amount of time discussing with you
[15:04] <needhelp1> nice to talk again
[15:05] <needhelp1> sladen: you been doing ok?
[15:05] <sladen> needhelp1: about how to improve the chance of getting survey data;  by eg. making questions such 'sex' optional, and moving them to the end;  and working with  OMG!Ubuntu, rather than trying to find users on a developer channel
[15:06] <needhelp1> sladen: yeah, thanks. I have had a lot of success with the survey.
[15:06] <sladen> needhelp1: IIRC, you were going to make the questions optional, and get in touch with OMG!Ubuntu by email
[15:06] <sladen> needhelp1: did you actually do either of these things?
[15:07] <Mirv> mitya57: please do a merge request so it shows here https://code.launchpad.net/~unity-team/libunity/trunk/+activereviews :) then we should hunt for someone to review it
[15:07] <Mirv> merge proposal, that is
[15:07] <needhelp1> yeah, i was asked by some ubuntu groups to leave the sex question as required
[15:08] <needhelp1> the stats for the sex question are in line with other ubuntu surveys , and a large effort was made to ensure equal access
[15:09] <mitya57> Mirv: that affects only packaging, so I've proposed a merge to lp:ubuntu/libunity
[15:09] <mitya57> https://code.launchpad.net/~mitya57/ubuntu/quantal/libunity/lp1055019/+merge/125881
[15:10] <mitya57> (I thought the right branch should be lp:~ubuntu-desktop/libunity/ubuntu, but that one seems quite outdated...)
[15:10] <Mirv> mitya57: ah, right, I didn't check it since I'm in a free software evening event atm. that's indeed the correct place.
[15:12] <sladen> needhelp1: who?
[15:27] <bdmurray> doko: could you look at bug 938869 again?  there are some new duplicates of it coming in in bug 1045726.
[15:29] <doko> bdmurray, the last time I tried, I couldn't reproduce it here. I'm sure I left a comment in a duplicate issue, or closed another one
[15:30] <bdmurray> doko: is there some additional information we need?
[15:31] <doko> bdmurray, ahh, see my comment in #12
[15:36] <user82> hi. can i report a bug via launchpad webinterface?
[15:36] <user82> or does this question go to #ubuntu-bugs?
[15:37] <ogra_> you shouldnt, but you can indeed
[15:37] <ogra_> better use the ubuntu-bug tool
[15:38] <user82> okay thanks. it is totally simple i am 100% sure no detailed report is needed
[15:57] <xnox> @pilot in
[16:06] <doko> getting nearer to the ocaml ftbfs
[16:10] <Laney> tkamppeter: your hplip diff is a bit crazy, what happened there?
[16:11] <Laney> https://launchpadlibrarian.net/117287697/hplip_3.12.6-3ubuntu1_3.12.6-3ubuntu2.diff.gz
[16:41] <bryceh> could someone accept the two nvidia-* packages in NEW?  https://launchpad.net/ubuntu/precise/+queue
[16:46] <infinity> bryceh: I'll look at them laterish.
[16:47] <bryceh> infinity, thanks
[16:50] <ev> pitti, bdmurray: replied to the merge proposal
[16:50] <ev> sorry that took so long
[16:50] <ev> was caught up in tasks I started before I went on holiday and wanted to finish them before they completely left my brain
[16:53] <Laney> tkamppeter: I'll reject it. There's an autogenerated debian-changes patch that you almost certainly don't want.
[16:58] <doko> bryceh, didrocks: is libtxc-dxtn-s2tc-bin needed in main too? if yes, please seed it
[17:01] <ev> seb128: still investigating, but it will have to go into tomorrow as I'm nearly done for the day. Just wanted to let you know that I haven't forgotten :)
[17:01] <seb128> ev, ok, thanks ;-)
[17:01] <seb128> ev, have a good evening!
[17:01] <ev> thanks! you too
[17:02] <xnox> @pilot out
[17:09] <bryceh> doko, I have a Recommends on it from mesa, do I also need to include it in seeds as well?
[17:09] <cjwatson> No
[17:09] <doko> hmm, still shows up in component mismatches
[17:10] <cjwatson> Assuming that the binary package with the Recommends is itself either directly seeded or included by way of transitive Depends/Recommends
[17:10] <bryceh> doko, the Recommends has been in for several days, so if you're still seeing it in component mismatches something is wrong
[17:10] <cjwatson> Which binary has the Recommends?
[17:10] <bryceh> libgl1-mesa-glx
[17:11] <cjwatson> No, that Recommends: libtxc-dxtn-s2tc0
[17:11] <cjwatson> At least in my apt cache
[17:11] <bryceh> doko, oh rats sorry I didn't actually read
[17:11] <bryceh> no, libtxc-dxtn-s2tc-bin is just some utilities, we don't care about that
[17:11] <doko> ok, demoting
[17:14] <ahasenack> SpamapS: hi, just a ping to say that I have updated my application at https://wiki.ubuntu.com/AndreasHasenack/LandscapeClientPerPackageUploadApplication, it probably has some things that weren't there when you endorsed it first
[17:15] <SpamapS> ahasenack: added some of your dark seedy past? ;)
[17:18] <doko> Daviey, I promoted the python-tornado binaries as well
[17:19] <ahasenack> SpamapS: ;)
[17:26] <doko> infinity, you did look at mksh in main this cycle, please could you have a look at the ftbfs?
[17:45] <infinity> doko: Yeahp, can do.
[17:52] <doko> hmm, ruby1.9.1 builds locally here. trying another buildd
[18:35] <Laney> doko: https://launchpadlibrarian.net/117310167/buildlog_ubuntu-quantal-amd64.webkit_1.9.91-0ubuntu1~build1_FAILEDTOBUILD.txt.gz
[18:36] <doko> bah ... will try again with a fresh chroot later
[18:38]  * doko curses gophers
[18:43] <doko> zul, Daviey: having a look at the nova and python-babel dependency
[18:43] <highvoltage> in the old days, people used to gopher curses.
[18:43] <doko> in the upstream ChangeLog I find: Adds Distutils.Extra support, removes Babel support, which is half-baked at best
[18:44] <doko> but: $ grep Babel nova.egg-info/*
[18:44] <doko> nova.egg-info/requires.txt:Babel>=0.9.6
[18:44] <doko> and dh_python2 adds this to the dependencies
[18:45] <doko> so to remove this, add Babel to debian/pydist-overrides
[18:45] <doko> are you ok with this change?
[18:45] <zul> doko:  which i did this morning
[18:45] <zul> in rc2 which is sitting in pending
[18:46] <doko> ahh, ok
[18:46] <tkamppeter> Laney, I don't knowm, I will try to do a clean rebuild.
[18:50] <tkamppeter> Laney, the problem is the build system, the original tarball seems to contain machine-generated build system files which get remade by "make clean", so I need to backup the build system to restore in the end of "make clean".
[18:51] <tkamppeter> popd
[19:03] <doko> the binutils fix did allow the ocaml build to succeed, and ruby given back on another buildd builds fine as well. time to finish for today ...
[19:09] <tkamppeter> Laney, still around
[19:09] <tkamppeter> Laney, still around?
[19:09] <Laney> tkamppeter: kind of, not to review/accept though
[19:10] <tkamppeter> Laney, I have some problem with HPLIP, I do not succeed to keep the build system files conserved.
[19:11] <tkamppeter> Laney, I save them in the "configure" rule, right after "dh_testdir" and restore them in the "clean" rule, AFTER dh_clean.
[19:11] <Laney> what do you mean save and restore?
[19:11] <Laney> are you using dh_autoreconf?
[19:13] <tkamppeter> Laney, the problem is that only running the "clean" rule (which runs the "configure" rule as dependency) the build system files get changed and so the change gets recorded as "debian/patches/debian-changes" in the source file.
[19:13] <kees> anyone around that knows efi booting? I'm trying to debug why my system won't... :P I can't figure out if I'm even loading the grub .efi file or not
[19:14] <tkamppeter> Laney, yes, I use "dh_autoreconf debian/autogen.sh" in the "configure" rule.
[19:14] <Laney> clean runs configure?
[19:14] <Laney> that sounds less than ideal
[19:15] <tkamppeter> Laney, I do not know why, the Debian maintainer must have added that. I will try to remove it.
[19:18] <Laney> tkamppeter: OK. Let's revisit it tomorrow if you want
[19:20] <infinity> pitti: This pkgbinarymangler diff looks curious.
[19:21] <tkamppeter> Laney, that's it, the "configure" dependency was wrong, I have removed it and now all works well. Thanks.
[19:28] <Laney> tkamppeter: ah, nice. I wonder why it was there. How curious.
[19:29] <tkamppeter> Laney, fixed package uploaded.
[19:31] <Laney> tkamppeter: if you want to close bugs, you need to upload with -v
[19:31] <tkamppeter> Laney, perhaps the debian/patches/debian-changes file was already there for longer time only that no one has taken note of it. Especially all these changes get overwritten on each package build, so that they do not break the software provided by the package.
[19:32] <Laney> alternatively, since they were never in the archive, you don't need to use a new version number
[19:34] <tkamppeter> Laney, now it is already uploaded, I will close the one bug report manually.
[19:34] <Laney> up to you. It's no problem to reupload multiple copies to the queue.
[19:35] <tkamppeter> Laney, does this mean that as the last upload is not yet approved I can do another upload with a lower version number?
[19:35] <doko> Laney, where was this fixed make version?
[19:36] <Laney> doko: https://launchpad.net/~laney/+archive/webkit/+packages
[19:40] <tkamppeter> Laney, now I have uploaded a new -3ubuntu2 with all the changes. So you can reject -3ubuntu4 and accept -3ubuntu2.
[19:41] <Laney> ack
[19:51] <doko> bdmurray, could you find out about the env vars which are set?
[19:51] <Laney>  7 files changed, 18 insertions(+), 11135 deletions(-)
[19:52] <Laney> tkamppeter: nice!
[19:53] <bdmurray> doko: what do you mean exactly?
[19:55] <doko> bdmurray, so what do you suggest to do? dear vmware, please fix your broken installer?
[19:57] <doko> bdmurray, I assume they ship a python2.x environment, and then calling everything else with this environment
[19:58] <bdmurray> doko: no, if its vmware's fault that's fine. I'd just like to be able to have that information in the bug and write a bug pattern for the crash if possible.  Also modifying apport so we know if python was modified seems like a good idea too.
[20:00] <doko> ok, so the bug pattern would be to look for something vmware'ish in PYTHONHOME and PYTHONPATH. I assume they only see this on Ubuntu, because other distros ship a lsb_release implemenation not written in python
[20:00] <bdmurray> and it doesn't look like apport gathers either of those
[20:04] <bkerensa> sconklin_: your PP today?
[20:04] <sconklin_> yes, what's up?
[20:04] <sconklin_> I'm only looking at kernel issues, fwiw
[20:12] <doko> bdmurray, even ProcMaps.txt doesn't show any references, because the error happens that early
[20:12] <smoser> pretty sure i just time traveled.
[20:12] <smoser> my clock now says 4 hours in the future
[20:13] <smoser> hm.. no, it just lost my timezone.
[20:13] <smoser> strange
[20:13] <Daviey> smoser: no, you fell asleep.. check for the key imprints on your face
[20:25] <bkerensa> sconklin_: oh nvm then :) just have a line of MP's waiting for review
[20:26] <sconklin_> bkerensa: as luck would have it, both PPs who were assigned today were kernel people
[20:27] <bkerensa> peh
[20:27] <bkerensa> :D
[20:28] <sconklin_> I'm almost EOD anyway
[20:53] <doko> Laney, so I was bad with testing. webkit ar failure still reproducible. maybe you could work around it by configureing with --disable-static?
[20:54] <Laney> maybe
[20:56] <cjwatson> kees: with GRUB 2.00, you can 'echo $grub_platform' to see which platform you're running (at least assuming GRUB has got out of rescue mode)
[20:59] <Sweetshark> doko: so, do you want that vigra drop still? If so, I would assume so for quantal+1, which is a bit of: could you drop a minibug on me for that then?
[20:59] <doko> Sweetshark, no, your are free to fix the ftbfs of libvigraimpex in q, as the only user of this package ;-P
[21:04] <Sweetshark> doko: hah!
[21:06] <Sweetshark> jasoncwarner_: ping?
[21:09] <doko> barry, ^^^ you did touch libvigraimpex before, maybe give it a try?
[21:11] <barry> doko: tbh, i've never actually used libvigraimpex
[21:12] <doko> ok
[21:15] <kees> cjwatson: after more debugging and running the efi shell from a usb stick, it seems like my ami firmware is refusing to notice my efisys partition, and I don't understand why.
[21:16] <kees> cjwatson: the HDD shows up under "devices" in the efi shell, but it doesn't see any partitions listed under "map", which only shows the usb stick.
[21:16] <kees> oddly, I created the partitions with the same tools: gdisk and mkfs.vfat
[21:30] <Laney> doko: --disable-static is the default
[21:30] <Laney> and we don't enable it
[21:40] <bryceh> infinity, chance you could peek at the nvidia NEW?  I'm hoping it should be an easy wave-thru for you since we got TB approval on it (http://ubuntu.5.n6.nabble.com/Minutes-from-the-Technical-Board-meeting-2012-09-17-td4992536.html)
[21:57] <infinity> bryceh: It's on my TODO today, don't worry.
[22:11] <TheLordOfTime> where can i report a possible issue with the retracer for a crash bug on a Quantal system?
[22:11] <TheLordOfTime> or am i asking in the wrong location
[22:16] <SpamapS> TheLordOfTime: here is probably a good place. Whats up?
[22:17] <TheLordOfTime> SpamapS, https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1056419  <-- should the retracer be expecting proposed repo packages to be used for testing?
[22:18] <SpamapS> TheLordOfTime: its entirely possible the retracer does not know how to deal with proposed.
[22:18] <TheLordOfTime> SpamapS, that might be something to look into, unless i'm misreading the retracer's whining
[22:19] <TheLordOfTime> libgtk2.0-0 version 2.24.13-0ubuntu1 required, but 2.24.13-0ubuntu2 is available  <-- that one caught my attention since -0ubuntu2 is only in proposed
[22:20] <TheLordOfTime> and unless you're an idiot, or a hardcore tester of everything, you don't run stuff from proposed very often.
[22:20] <TheLordOfTime> if at all.
[22:21]  * micahg would think it's more likely that the ddebs are removed before stuff in moved to the release pocket
[22:25] <cjwatson> find pitti when he's around and ask him; not sure anyone else really knows how the ddeb publisher works
[22:25] <cjwatson> but I could well imagine that it fails to handle the -proposed workflow somehow
[22:26] <TheLordOfTime> cjwatson, that was my thought
[22:26] <Laney> I've definitely had apport refuse to let me file a bug because of -proposed
[22:27] <TheLordOfTime> cjwatson, the main reason i saw that is it  was a quantal bug, and it was invalid'd pretty much when it got on the feed the announce bot in #ubuntu-bugs-announce posted it, and I dont usually see that.  'Tis why I was curious, then i saw that
[22:28] <TheLordOfTime> cjwatson, if the retracer's processing -proposed as if it is an approved, uploaded package to the standard repos, then the retracer needs an overhaul
[22:28] <TheLordOfTime> since that's a possibility of legitimate crash bugs being invalid'd because of -proposed
[22:28] <micahg> well, what we need is ddeb support in soyuz
[22:29] <cjwatson> we know the retracer needs an overhaul; in this case though it should be a relatively small fix
[22:31] <TheLordOfTime> cjwatson, then a targetted code stabbing session should work :P  but my original point stands: at least with $currentDevRelease it can result in legit crash bugs being marked invalid and thereby being completely ignored by devs, which can definitely lead to reported-but-not-fixed issues at release
[22:31] <Laney> Nobody is disagreeing with you
[22:31] <TheLordOfTime> :)
[22:31] <TheLordOfTime> Laney, indeed.  i'm just reiterating my point :)
[22:31] <TheLordOfTime> as a triager, i don't like broken stuff, esp. if the retracer is doing othe breaking :p
[22:32]  * TheLordOfTime returns to lurkmode