[00:32] <jibel> skaet, I verified sru bug 607657 on both amd64 and i386, also verified that the following packages upgrade correctly and that the system reboots after the upgrade: base-files, consolekit,  eglibc, grub2, unattended-upgrades, upstart, xserver-xorg-video-geode
[00:32] <ubot4> Launchpad bug 607657 in debian-installer (Ubuntu Lucid) (and 3 other projects) "Lucid point release installer must support LTS backported Kernels (affects: 2) (heat: 28)" [High,Fix committed] https://launchpad.net/bugs/607657
[00:33] <jibel> I've verified that lsb_release returns the right version too. I'll add a comment on the bug report tomorrow morning (mine), good night all
[01:41] <skaet> jibel,  thank you!  :)
[08:57] <jibel> ara, pitti, I verified sru bug 607657 on both amd64 and i386, also verified that the following packages upgrade correctly and that the system reboots after the upgrade: base-files, consolekit,  eglibc, grub2, unattended-upgrades, upstart, xserver-xorg-video-geode
[08:57] <ubot4> Launchpad bug 607657 in debian-installer (Ubuntu Lucid) (and 3 other projects) "Lucid point release installer must support LTS backported Kernels (affects: 2) (heat: 28)" [High,Fix committed] https://launchpad.net/bugs/607657
[08:57] <ara> thanks a lot jibel
[08:57] <jibel> I've verified that lsb_release returns the right version too. Anything other thing to check for sanity ?
[08:58] <jibel> I'll update the reports.
[09:16] <cjwatson> skaet: the morning's CD builds have mostly been hamstrung by the new X packages, which aren't coinstallable yet.  I'll try to push things uphill until jdstrand is around ...
[09:17] <skaet> cjwatson, thanks.  We
[09:18] <skaet> are having storms here, and I don't have power to the house, so jdstrand may be affected as well.
[09:18] <skaet> internet is on UPS - so I guess we'll see how long its battery lasts ;)
[11:38] <ara> pitti, cjwatson: are eglibc and d-i now ready to be moved to -updates?
[11:38] <pitti> they are; I already did eglibc
[11:38] <pitti> (and a few others)
[11:39] <pitti> d-i needs special treatment, I'll do that today
[11:39] <pitti> I asked about testing tbird-locales, should happen today (from Chris)
[11:39]  * ara hugs pitti
[11:39] <ara> thanks!
[11:39] <jibel> pitti, you can publish base-files too, there is no bug report for it.
[11:39] <pitti> then casper is the only thing which is still in -proposed
[11:40] <pitti> jibel: right, that's just the "I'm 10.04.2" bump
[11:40] <pitti> jibel: many thanks for all these verifications
[11:40] <jibel> pitti, correct. and I've verified that lsb_release displays 10.04.2 :-)
[11:43] <jibel> pitti, for x-x-v-geode, I verified that it installs but I don't have this hw so it really proves nothing. only q-funk could do a valid verification.
[11:43] <pitti> jibel: right, I already prodded him to give it a test
[11:43] <pitti> ah, and grub2 still needs testing
[11:44] <pitti> ara: so what was the plan now? do cert on the proposed images, or wait until everything is verified?
[11:44] <ara> pitti, we will start with the -proposed images
[11:44] <jibel> pitti, and for grub, strangely this morning usb-creator crashes on me when I want to create create a bootable memory stick.
[11:45] <ara> pitti, the only need of waiting on those packages to move to -updates was to be able to know that validation was fine :)
[11:45] <ara> pitti, we will start as soon as possible testing on a broad range of hardware, to test if everything is still OK
[11:46] <pitti> cool
[11:46] <ara> Hopefully there won't be any regressions
[11:46] <ara> fingers crossed
[11:46] <ara> we will be posting results in a report as we go, we will let you know where it is
[12:13] <Riddell> new package doesn't contain the full licence text but a URL to the licence, reject?  (http://paste.kde.org/3879/)
[12:23] <cjwatson> is that in debian/copyright or in an upstream file?
[12:24] <Riddell> both
[12:24] <cjwatson> the upstream file does not need to change
[12:24] <cjwatson> (as Steve and I have been saying for ages)
[12:24] <cjwatson> debian/copyright needs to comply with policy, though
[12:24] <cjwatson> should be as simple as inserting a reference to /usr/share/common-licenses/Apache-2.0
[12:25] <pitti> I object
[12:25] <pitti> well, GPL requires it
[12:25] <pitti> and this one kind of does
[12:25] <pitti> "You must give any other recipients of the Work or Derivative Works a copy of this License"
[12:25] <cjwatson> that's why it's in common-license
[12:25] <cjwatson> s
[12:26] <cjwatson> the upstream file does not need to change because (a) upstream is the licensor not a licensee and can do what it likes (b) we shouldn't encourage people to change upstream files when it isn't necessary.  a reference to the common-licenses file in debian/copyright satisfies our licensing obligations
[12:26] <pitti> right, but I still consider it an upstream pacakging error to not ship the license
[12:27] <cjwatson> it might be a justification for a polite mail to upstream asking if they can ship it
[12:27] <pitti> *nod*
[12:27] <cjwatson> it is absolutely not a justification for a reject
[12:27] <pitti> I agree
[12:27] <cjwatson> (although the debian/copyright error is)
[12:27] <Riddell> I'll reject, thanks
[12:27] <pitti> I do reject GPL packages which don't ship a copy, though, as the GPL wording is quite strong in that regard
[12:28] <cjwatson> we meet our obligations there by shipping it with the system
[12:28] <cjwatson> that's the whole point of common-licenses
[12:29] <cjwatson> suppose it depends what you think "along with" means
[12:30] <pitti> to me it means "is the orig.tar.gz redistributable"
[12:30] <pitti> which it wouldn't be if it wouldn't have a GPL copy
[12:30] <pitti> we made some concessions for that in the past
[12:30] <cjwatson> I'm concerned that this policy encourages people to modify orig.tar.gz files
[12:30] <pitti> such as "I told upstream, and they'll ship it in the  next release"
[12:31] <cjwatson> it is IMO clearly sufficient to put it in the diff.gz/debian.tar.gz
[12:31] <pitti> at which point I  accepted them
[12:42] <Riddell> three rejects today, I'm on a roll :)
[13:13] <Riddell> the benevolent dictator has confirmed bug 709980, does that mean I don't need to wait for ubuntu-sru to confirm it?
[13:13] <ubot4> Launchpad bug 709980 in ubuntu-font-family-sources (Ubuntu Karmic) (and 5 other projects) "SRU ubuntu-font-family 0.70.1 for * (affects: 2) (heat: 16)" [Undecided,New] https://launchpad.net/bugs/709980
[13:16] <jibel> cjwatson, pitti, can we start testing alternate images ? there's nothing for a2 on the tracker.
[13:17] <cjwatson> jibel: no, needs X fixed
[13:17] <cjwatson> I'll post to the tracker when stuff is ready
[13:18] <cjwatson> Riddell: in general you don't need to wait for ubuntu-sru to confirm something before upload anyway; we review from the queue
[13:18] <jibel> cjwatson, okay, thanks
[13:18] <cjwatson> it's only if you want some kind of design review
[13:22] <Riddell> cjwatson: it is in the queue, I'm asking if I can accept it
[13:24] <cjwatson> not for lucid (10.04.2 freeze); it's OK for other releases if it passes your review
[13:24] <cjwatson> (IMO)
[14:00] <jibel> pitti, I verified casper, grub2 and srtp in lucid,
[14:00] <pitti> wow, thanks!
[14:00] <jibel> I've never been able to reproduce the eclipse bug
[14:00] <pitti> for that a "package stilll works" is probably sufficient at this point IMHO
[14:01] <jibel> okay, you need moon as well ?
[14:01] <pitti> no, it's not on any CD
[14:01] <pitti> eclipse isn't either, I think
[14:01] <pitti> (no Task: header)
[14:03] <cjwatson> FWIW, to whoever did main syncs, I was deliberately avoiding main syncs due to the soft freeze
[14:03] <cjwatson> universe syncs are fine
[14:14] <jdstrand> I have power
[14:14] <jdstrand> and am here now
[14:15]  * jdstrand is reveiwing backscroll and email
[14:15] <cjwatson> jdstrand: status: waiting for pile of X uploads to build so that http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html looks like less of a disaster area and we can actually have CD builds that work
[14:15] <cjwatson> xserver-xorg-input-mouse still needs a non-trivial upload
[14:18] <pitti> cjwatson: FYI, d-i copied to lucid-updates, according to the wiki procedure
[14:18] <pitti> (plus sru-release lucid d-i)
[14:18] <jdstrand> cjwatson: ok, thanks. is there anything you need me to do right now to help? I was planning at looking at the various reports (nincluding that one) and reviewing the antimony emails for things to work on
[14:19]  * jdstrand notes armel seems particularly cranky
[14:19] <jdstrand> I'm guessing that is a secondary priority though
[14:26] <cjwatson> jdstrand: most of the X crankiness on armel should be fixed soon
[14:26] <cjwatson> pitti: thanks
[14:27] <cjwatson> pitti: did you stop the publisher for it, or run it when the publisher was quiet anyway?
[14:27] <cjwatson> jdstrand: the libreoffice stuff can/has-to be ignored on armel for the time being, AIUI
[14:28] <pitti> cjwatson: I did that in dists.new, as the wiki page says (and confirmed that it was still present afterwards)
[14:28] <pitti> I'll check on http://archive.u.c./ after the next publisher run, though
[14:28] <cjwatson> and KDE seems busted on armel for one reason or another
[14:28] <cjwatson> pitti: ok, thank
[14:28] <cjwatson> s
[14:29] <cjwatson> jdstrand: I think once this X hairball lands I'll try another full batch of CD builds, and then let you wrestle with whatever falls out of that
[14:33] <jdstrand> cjwatson: ok
[14:34] <jdstrand> cjwatson: I was looking at kde on friday. as of then, it is a snowball effect of kdebase not building
[14:34] <jdstrand> Riddell: fyi ^
[14:35] <jdstrand> I didn't look beyond that yet
[14:35] <Riddell> jdstrand: well it's kdebindings that's the blocker on arm
[14:35] <jdstrand> Riddell: ok, so you are aware of it. cool. is that going to be fixed for alpha2?
[14:36] <Riddell> jdstrand: doesn't seem like it, I can't work out why it's failing :(
[14:37] <jdstrand> Riddell: perhaps that is something doko look at if it is a tool chain issue?
[14:38] <jdstrand> s/look at/provide guidance, etc/
[14:38] <cjwatson> doko's on holiday for the next two weeks
[14:38] <jdstrand> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I/build/buildd/gtk+2.0-2.23.90/gtk -I.. -DG_LOG_DOMAIN=\"Gtk\" -DGTK_LIBDIR=\"/usr/lib\" -DGTK_DATADIR=\"/usr/share\" -DGTK_DATA_PREFIX=\"/usr\" -DGTK_SYSCONFDIR=\"/etc\" -DGTK_VERSION=\"2.23.90\" -DGTK_BINARY_VERSION=\"2.10.0\" -DGTK_HOST=\"arm-unknown-linux-gnueabi\" -DGTK_COMPILATION -DGTK_PRINT_BACKENDS=\"file,cups\" "-DGTK_PRINT_PREVIEW_COMMAND=\"evince --unlink-tempfile --preview --print-sett
[14:38] <jdstrand> sip: KPlotAxis::majorTickMarks() unsupported function return type - provide %MethodCode and a C++ signature
[14:38] <jdstrand> holy cow that line was way longer than I thought
[14:39] <jdstrand> sorry about that!
[14:39] <jdstrand> heheh
[14:39] <Riddell> -x PyQt_qreal_double should set double to be qreal and get round the qreal != double issue
[14:40] <Riddell> I can't see anything which has changed in the pykde source
[14:41] <Riddell> it's a new sip4 and py-qt4 version but upstream says nothing has changed there
[14:41] <Riddell> and indeed /usr/share/sip/PyQt4/QtCore/qglobal.sip still has the typedef in it
[14:41] <jdstrand> I've not looked at this or the kdebindings build issue before
[14:42] <jdstrand> what does -x PyQt_qreal_double do to affect the compile?
[14:42] <Riddell> NCommander has worked on it before but he doesn't seem to be interested in it now
[14:42] <jdstrand> ah, ok
[14:42] <Riddell> it should do typedef double qreal;
[14:42] <Riddell> from qglobal.sip
[14:42] <jdstrand> maybe we should poke him
[14:43] <Riddell> or bribe him
[15:04] <cjwatson> so I *think* we should be good to go for images other than Kubuntu armel in a bit over an hour and a half
[15:04] <cjwatson> by that point the remaining X stuff should have landed, along with new ubiquity
[15:04] <cjwatson> maybe not powerpc
[15:04] <charlie-tca> cjwatson: don't spin the xubuntu powerpc
[15:04] <cjwatson> ok, what's wrong with it?
[15:05] <charlie-tca> it don't work and I don't have a tester
[15:05]  * cjwatson makes yet another mental note to get that mac mini set up
[15:19] <jdstrand> filed bug #711293 (apache2)
[15:19] <ubot4> Launchpad bug 711293 in apache2 (Ubuntu Natty) (and 1 other project) "[natty] apache2 FTBFS on amd64 (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/711293
[15:19] <jdstrand> looks like axis2c won't be fixed for alpha2 (bug #600174)
[15:19] <ubot4> Launchpad bug 600174 in axis2c (Ubuntu Natty) (and 2 other projects) "axis2c fails to build from source on maverick/i386 (affects: 4) (dups: 2) (heat: 41)" [High,Confirmed] https://launchpad.net/bugs/600174
[15:19] <jdstrand> (followed up with server team)
[15:20] <jdstrand> also kdebindings probably won't be fixed for alpha-2
[15:20] <jdstrand> (followed up with arm team)
[15:36] <Daviey> jdstrand, I am going to take another sniff of axis2c today.
[15:36] <jdstrand> Daviey: cool, thanks :)
[15:36] <Daviey> I hate it, i hate it! :)
[15:37]  * jdstrand is sorry to bring it up
[15:37] <Daviey> heh
[15:38]  * skaet is glad jdstrand brought it up
[15:39] <jdstrand> skaet: hi! do you have power back on?
[15:40] <skaet> yup,  got it back now.
[15:40] <jdstrand> nice. crazy winds
[15:40] <skaet> have half a tree in my backyard to deal with now at some point
[15:40] <jdstrand> :(
[15:41] <pitti> hey skaet, good morning
[15:41] <highvoltage> hectic
[15:41] <skaet> hey pitti, good afternoon.
[15:42]  * skaet working through the irc log now - but parts not updated yet.
[15:43] <jdstrand> skaet: oh, been meaning to ask you. dapper server is going eol in june and hardy desktop in april-- are you planning to send a pre-eol announcement? I think slangasek would do it 3 months before... if this is in a wiki, feel free to point me at it
[15:43] <skaet> jdstrand: just a sec, and I'll get the link and double check as well.
[15:45] <skaet> whew... its just 30 days before, so we're fine. :) https://wiki.ubuntu.com/EndOfLifeProcess
[15:47] <skaet> and yup, I'll send it out and work through the checklist, do the negotiations with OEM, etc.
[15:47] <jdstrand> skaet: thanks for the link. I wonder if it should be sooner for LTS? maybe not, but my thinking is that the types of people who stay on LTS may need more time to test upgrades, etc. of course, they are probably aware of the EOL
[15:47] <jdstrand> skaet: just a thought...
[15:47] <skaet> jdstrand,  its a good thought
[15:49] <skaet> I was planning on pinging marketing to see if they wanted to do something public about dapper server (first ever LTS release EOL'd)
[15:54] <skaet> jdstrand:  will dig into the implications of sending out an EOL pre-announce for the LTS (2 months prior?, then repeat at 30 days) next week, after A2 is out.  ;)
[15:56] <jdstrand> skaet: cool, thanks. it looks like I misremembered. All I could find was https://lists.ubuntu.com/archives/ubuntu-announce/2009-July/000123.html which was a month (or so) before
[15:56] <jdstrand> (dapper eol)
[15:58] <skaet> jdstrand:  thanks for the link to dapper's eol.   It will be appropriately cribbed in due time, ;)
[16:45] <cjwatson> sigh, kde4libs update meant that amd64 exploded
[16:46] <cjwatson> publisher on manual, I don't have all day
[16:49] <Riddell> yeah sorry about that, I shouldn't have uploaded that
[16:52] <JamieBennett> Hi cjwatson, can you give me an update on the x uploads? Wondering when i can respin images for Linaro again.
[16:54] <smoser> does anyone know of reasons that I would not be able to start UEC / EC2 image testing on last nights build ?
[16:54] <smoser> or would there be something important missing from them.
[17:03] <cjwatson> JamieBennett: X is done, just sorting out kde4libs
[17:05] <JamieBennett> Ok, thanks
[17:26] <smoser> the only update that I see from current 20100102 images and what the archive has is libdb4.8
[17:26] <smoser> the changelog doesn't mention anything seemingly relevant for me
[17:27] <smoser> so, i would guess unless there are objections, that I'm asking someone to populate the iso tracker from http://uec-images.ubuntu.com/server/natty/20110201/ (http://uec-images.ubuntu.com/server/natty/20110201/published-ec2-daily.txt)
[17:28] <smoser> but i guess iso tracker hasn't even started alpha-2 testing yet.. .so maybe im'just too early
[17:28]  * cjwatson thinks
[17:28] <cjwatson> server's probably OK
[17:30] <cjwatson> smoser: remind me what file I'm supposed to use as input to post-amis-to-iso-tracker.py?
[17:30]  * smoser searches
[17:31] <cjwatson> I'm sure I used to know
[17:31] <cjwatson> it's supposed to be parseable like this:
[17:31] <cjwatson>                 zone,ami,arch,store = line.split()[0:4]
[17:31] <cjwatson>                 if not ami.startswith('ami-'):
[17:31] <cjwatson>                         continue
[17:31] <smoser> lp:~ubuntu-archive/ubuntu-archive-tools/trunk/post-amis-to-iso-tracker.py
[17:31] <cjwatson> yes
[17:32] <smoser> 'hvm' in store is possibly going to break you
[17:32] <smoser> which is a new deliverable.
[17:32] <cjwatson> I can't find the file to supply as input to that script, though
[17:33] <cjwatson> I'm happy to try to fix up the script ...
[17:34] <smoser> the second link in above
[17:34] <smoser> http://uec-images.ubuntu.com/server/natty/20110201/published-ec2-daily.txt
[17:35] <cjwatson> oh, bah, sorry, missed that
[17:36] <skaet> jdstrand, pitti, cjwatson - have cleaned up iso.qa.ubuntu.com.   Its ready for the images to go up, when they come off the builds.
[17:36] <cjwatson> ok, so what should I do with the hvm deliverable?
[17:36] <cjwatson> I wonder how flexible the testcase naming is
[17:37] <cjwatson> if it'll just accept us-east-1-amd64-hvm, we may be OK
[17:37] <cjwatson> oh, right, there's a numerical map
[17:38] <smoser> yeah, so right now there isn't a test case for it, and i'm not going to test it like i have the others
[17:38] <smoser> so i guess, if you can add a test group for it, that would be good.
[17:39] <cjwatson> test group?
[17:40] <cjwatson> I can add a test case id for it in the tracker, but have no idea how to make that have useful backend data
[17:40] <smoser> hm... well, i guess do the first step.
[17:41] <smoser> i have no idea either.
[17:42] <cjwatson> just call it "Ubuntu Server EC2 HVM (US-East) amd64"?
[17:43] <smoser> yeah
[17:44] <cjwatson> bah, it's supposed to have a URL
[17:44] <cjwatson> I can't even find the list of existing testcase URLs
[17:45] <cjwatson> http://testcases.qa.ubuntu.com/Install doesn't include anything for EC2 AFAICS
[17:46] <cjwatson> stgraber,jibel: do you have any idea what I should use as a testcase URL for a new EC2 deliverable?
[17:47]  * stgraber looks at the DB for similar testcases
[17:47] <cjwatson> is there anything private in the ISO tracker DB?  password hashes I guess ...
[17:48] <stgraber> we could probably export part of the DB at least, it's a Drupal instance so exporting just the data of the qatracker module should be fine
[17:48] <stgraber> looks like I no longer have ssh access to the box hosting the QA tracker ...
[17:48] <stgraber> used to be on quandong.canonical.com but got moved to something else and I don't know the name of the new server ...
[18:04]  * cjwatson looks at powering up the mac mini persia gave him and discovers it has a deeply alarming power plug which I don't want to plug into anything here
[18:04] <cjwatson> I think I'll get a native end for the power brick tomorrow instead ...
[18:04] <cjwatson> it has an earth wire which apparently you're supposed to do this with: http://www.binchoutan.com/alfa-genius/images/fielder/img1_13.jpg
[18:05] <highvoltage> isn't that a normal american plug?
[18:05] <cjwatson> never seen a US plug with the additional spadeclip earth wire
[18:06] <cjwatson> which you're meant to screw onto a post attached to your socket
[18:07] <skaet> sweet!  just finished looking at the A1 release note bugs, and all those with numbers are actually fix released/resolved. :)
[18:07] <highvoltage> heh, weird
[18:08] <ScottK> Riddell: It looks like I asked for that powerpc respin yesterday too soon as it came in the same size.  Could we respin it again?
[18:10] <cjwatson> stgraber: do you think I might be able to just use a blank URL?
[18:10] <davmor2> latest x drivers update seem to of broken unity I get just the background and white mouse cursor and nothing else :(  It was working fine-ish yesterday
[18:11] <Riddell> ScottK: I think now we need to wait for the alpha 2 candidates to appear
[18:12] <ScottK> Riddell: OK.  That'll be fine.  I wasn't sure if we'd got that far yet or not.
[18:12] <ScottK> (I'm offline most of today and tomorrow)
[18:12] <stgraber> cjwatson: IIRC an external testcase isn't even a requirement (in the code, might be in the process), so you should be able to add one without an URL, then whenever we find someone with DB access we can change it
[18:14] <jibel> cjwatson, there are 3 testcases for uec http://testcases.qa.ubuntu.com/Install/ServerUECTopology[1-3]
[18:14] <cjwatson> jibel: this is EC2 rather than UEC
[18:16] <jibel> cjwatson, oh right. I think you can go with a blank, I'll update it later.
[18:32] <jibel> cjwatson, the testcase url for ec2 is http://testcases.qa.ubuntu.com/System/EC2CloudImages
[18:53] <cjwatson> jibel: I tried both that URL and a blank URL, but it just ignores me (doesn't show the new testcase in the list, and doesn't show an error)
[18:53] <cjwatson> jibel: can you try, if you have admin access?
[18:53] <cjwatson> server and Kubuntu images building, pending that
[19:23] <cjwatson> Ubuntu server posted
[19:44] <jibel> cjwatson, for which product and what is the testcase title ?
[19:56] <cjwatson> jibel: "Ubuntu Server EC2 HVM (US-East) amd64"
[19:56] <cjwatson> (for Ubuntu, of course)
[20:06] <jibel> cjwatson, I've added it to the list of products, now you should see it in the testcase management page. Do I add the 2 testcases "EC2 User Data" and "EC2 Multiple Instances Run" ?
[20:11] <cjwatson> ah, I see, I was working on the wrong page
[20:12] <cjwatson> can you make it match whatever the other EC2 products say?
[20:16] <jibel> cjwatson, done. the menu "Manage Testcases" is misleading because it lists products and there is no way to list the test cases in the tracker. This tool definitely needs some love.
[20:16] <cjwatson> yeah
[20:16] <cjwatson> thanks!
[20:16] <jibel> yw
[20:18] <cjwatson> smoser: posted now
[20:18] <smoser> thank you cjwatson
[20:20] <cjwatson> Kubuntu alternate/desktop posted
[20:20] <cjwatson> not sure how much more we can do until unity's fixed
[20:22] <cjwatson> can somebody else take over whatever CD builds are needed and possible, and post them to the tracker?  see #ubuntu-devel (Amaranth etc.) for general state of unity, and keep an eye on http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html for what images it's possible to build
[20:22] <cjwatson> it's probably possible for somebody to do Xubuntu
[20:22] <cjwatson> but I want to finish for the day now
[20:26] <skaet> cjwatson,  I'll go in and start off Xubuntu then.
[20:27] <skaet> jdstrand,  can you keep an eye on the natty_probs?
[20:29] <jdstrand> skaet: sure
[20:36] <jdstrand> fyi, probs is in pretty good shape except for libreoffice/oo.o (excluding armel, which, as stated before, is cranky)
[20:36]  * jdstrand continues to keep an eye on it
[20:48] <apw> is unity core dumping and dropping you into classic known with the archive as of half hour ago?
[20:49]  * apw waves at skaet
[20:50]  * skaet refocuses back on this
[20:51] <skaet> apw, yes,  we're treating this as a blocking issue for A2 right now for the release
[20:51] <apw> skaet, sounds like you are goiong to be having fun
[20:52] <skaet> apw, indeed.  :(
[20:53] <apw> skaet, is there a bug number do you know, as i have an affected system it can be used to test
[20:53] <skaet> apw, I've been snagging the bug numbers as I see them into the release notes,  see under desktop section.
[20:54]  * skaet notes them now, and will work with desktop team to make them pretty tomorrow
[20:55] <apw> skaet, where are the release notes :)
[20:58] <skaet> ara,  https://wiki.ubuntu.com/NattyNarwhal/TechnicalOverview
[21:02] <smoser> ok. i found a bug (bug 711480) in ec2 images testing
[21:02] <ubot4> Launchpad bug 711480 in cloud-init (Ubuntu) "user-data scripts do not run (affects: 1) (heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/711480
[21:02] <smoser> and would like to re-spin for it.
[21:03] <smoser> so someone can take down the posted AMIs that cjwatson scrambled for me for.
[21:05]  * apw_ switches to a test box which is at least working ...
[21:05] <skaet> smoser, will do
[21:28] <jdstrand> filed bug #711512
[21:28] <ubot4> Launchpad bug 711512 in libreoffice (Ubuntu Natty) (and 1 other project) "[natty] libreoffice uninstallable: depends on ttf-sil-gentium-basic from universe (affects: 1) (heat: 6)" [High,New] https://launchpad.net/bugs/711512
[21:29] <jdstrand> skaet: that ^ will affect DVD builds, but CDs should otherwise be ok
[21:30] <jdstrand> at least, afaics
[21:30]  * skaet looking
[21:30] <jdstrand> ah yes
[21:33] <jdstrand> well, it might be a recommends
[21:33]  * jdstrand still looks
[21:34] <skaet> jdstrand,  do we document, or will kicking off a new build pick it up?
[21:35] <jdstrand> I haven't uploaded anything, I just discovered the issue. I am not sure it will prevent the DVD from building. it seems to be related to various spell checkers
[21:35] <jdstrand> the dependencies are a bit swirly, let me keep looking
[21:36] <pitti> jdstrand: these are recommends only, should be fine
[21:36] <pitti> see http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[21:36] <pitti> ah, sorry
[21:37] <pitti> ttf-sil-gentium is a recommends
[21:37] <pitti> -basic isn't
[21:37] <pitti> so that will cause trouble
[21:37] <jdstrand> right
[21:37] <jdstrand> I'm just trying to see what is pulling that in on natty_probs.html
[21:38] <jdstrand> my crappy germinate grepper tells me:
[21:38] <jdstrand>  ubuntu.natty/dvd: * myspell-de-de-oldspell # non-default alternative for language-support-de ubuntu.natty/dvd: * myspell-fr # myspell-fr-gut preferred
[21:38] <jdstrand> meh
[21:38] <jdstrand>  ubuntu.natty/dvd: * myspell-de-de-oldspell # non-default alternative for language-support-de
[21:38] <jdstrand>  ubuntu.natty/dvd: * myspell-fr # myspell-fr-gut preferred
[21:40] <jdstrand> so mysqll-fr has:
[21:40] <jdstrand> dictionaries-common (>= 0.10) | openoffice.org-updatedicts
[21:41] <jdstrand> oh, meh, openoffice.org-updatedicts isn't anywhere anyway
[21:42] <jdstrand> and dictionaries-common seems ok
[21:44] <ogra> did anyone trigger armel builds yet ?
[21:44] <jdstrand> myspell-de-de-oldspell suggests openoffice.org
[21:46] <jdstrand> it seems maybe it won't keep the DVD from building, if that is the only issue
[21:56] <ogra> hmpf seems we have a problem with the armel builders and empathy ftbfs without producing a log
[21:57] <ogra> lamont, any idea ?
[22:00] <ogra> lamont, seems it always ends up on one of the new builders
[22:00]  * ogra gives back again
[22:01] <lamont> ogra: yeah -give it back one more time now that the builders are happy again, and  I'll watch it
[22:01] <ogra> k
[22:02] <ogra> its on buttercup this time
[22:02] <lamont> sorry about all the fail on that page, fwiw
[22:02] <ogra> i dont care, the missing log was bothering
[22:02] <ogra> the page is just icons :)
[22:03] <lamont> heh
[22:08] <ogra> lamont, still filed without log
[22:08] <ogra> *failed
[22:10] <lamont> ogra: yeah... smack it one more time
[22:11] <ogra> done
[22:12] <ogra> wohoo
[22:12] <ogra> logs
[22:13] <ogra> that looks better
[22:16] <lamont> root cause identified and fixed then. :(
[22:17] <ogra> k
[22:17] <ogra> thanks for the quick fix
[22:34] <ogra> pitti, are you driving antimony tonight ?
[22:37] <skaet> xubuntu is now pushed out
[22:40] <ogra> skaet, for arm we will have to wait until https://launchpad.net/ubuntu/+source/empathy/2.32.2-0ubuntu8/+buildjob/2237015 is finished and published
[22:41] <skaet> ogra,  let me know when it publishes, and I'll kick off the builds.
[22:48] <ogra> GrueMaster, can you watch it and tell skaet ? i actually planned to sleep at some point tonight
[22:48] <GrueMaster> Can do.
[22:48] <ogra> (or delegate to NCommander ;) )
[22:48] <ogra> after he returned
[22:52] <ogra> i hope thats the only package that slipped through
[22:53] <skaet> thanks ogra, GrueMaster
[22:53] <ogra> (would be really helpful if an uploader who uploads during a freeze could notify us about failed arm builds, i wouldnt have noticed it if GrueMaster hadnt just stumpled over it)
[22:54] <ogra> i#m pretty sure ken got a mail for the buildfailure
[23:16] <lamont> ogra: fwiw, I retried 14 builds from earlier today, some of those were natty/release
[23:17] <lamont> 2236478 2236483 2236979 2236989 2237017 2237048 2237049 2237051 2237110 2237125 2237129 2237147 2237196 2237208 <-- to be specific
[23:17] <lamont> http://launchpad.net/builders/+buildjob/$id
[23:18] <lamont> those were all builds that retry-timed-out today, so they should all have been post-freeze uploads in any case
[23:18] <lamont> and presumably are the ones you'd have been wondering about sometime between now and alpha2
[23:20] <GrueMaster> skaet: Build finished successfully.  Awaiting publication.
[23:21] <skaet> Thanks GrueMaster,  let me know when you see it published, and I'll add it in to the image build list.
[23:22] <GrueMaster> ok.  I am monitoring from an earlier image to make sure dist-upgrade doesn't break on anything else.


[12:12] <kiko> Z3 uses interfaces to specify elements in a form
[12:12] <flacoste> sivang: it's normal, they are confusing but the relationship is that a form (or view) usually uses a schema (an interface) to specify the fields it contains as well as the validation constraints of that schema
[12:12] <kiko> I'm not sure that is conflating
[12:13] <flacoste> or like kiko said in less word :-)
[12:13] <kiko> the launchpad tree makes it confusing though
[12:15] <matsubara> sivang: i think the bug you just reported is a dupe of bug 52330, could you check?
[12:15] <Ubugtu> Malone bug 52330 in launchpad "Reassign bug to binary package should just work" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52330
[12:15] <flacoste> sivang: in an edit form each field in the schema will have a corresponding widget and the widget usually delegates validation to the field (that's the Choice in your case)
[12:15] <sivang> matsubara: /me checks
[12:16] <matsubara> or perhaps bug 1922
[12:16] <Ubugtu> Malone bug 1922 in malone "Unhelpful "Invalid value" error when requesting fix for non-existent package/product" [Medium,Confirmed]  http://launchpad.net/bugs/1922
[12:16] <matsubara> but i'm outta here
[12:16] <matsubara> see you guys tomorrow
[12:16] <sivang> matsubara: laters
[12:16] <matsubara> good night all
[12:17] <flacoste> sivang: another important thing you will want to know:
[12:18] <flacoste> field validation will raise an exception when the value is incorrect
[12:19] <flacoste> each errors can be rendered differently based on its type
[12:20] <flacoste> the widget will try to find a view registered for the specific type
[12:22] <sivang> flacoste: thanks, see you later then.
[12:22] <flacoste> sivang: feel free to ping me tomorrow if you need further clarifications on how all of this fits together
[12:23] <sivang> flacoste: will do, many thanks.
[12:42] <sabdfl> kiko, flacoste: it's absolutely conflating the two
[12:42] <sabdfl> interfaces have Attribute's too
[12:42] <sabdfl> which have no place in a schema
[12:43] <kiko> sabdfl, doesn't it seem that way just because we store them all in the same place? I get that impression at least
[12:43] <sabdfl> the worst example of this is cases where the same attribute needs to be on multiple forms, with different help-text
[12:43] <kiko> if we had a place for forms/ and another for interfaces/..
[12:43] <kiko> hmm
[12:43] <kiko> yeah, I don't know!
[12:43] <sabdfl> for example, the new SpecSubscription.essential field
[12:44] <sabdfl> when you are editing YOUR subscription, the text wants to be different to when you are editing that of someone else
[12:44] <sabdfl> z3 does so many things the hard way, it still amazes me that people fell for this conflating short cut
[12:45] <sabdfl> kiko: that was a very good reply to the pythonista's again - thank you!
[12:46] <kiko> sabdfl, trying hard to give us a really good public impression
[12:46] <sabdfl> also, since you are Mr Review, there's this little branch i worked on over the weekend...
[12:46] <sabdfl> *most* of the 3,000 lines are [trivial]
[12:46] <sabdfl> ;-)
[12:46] <kiko> oh that's what that praise was about!
[12:47] <kiko> well
[12:47] <sivang> sabdfl: somewhere in the phillikon book, I think it explains that Views (= forms?) Are basically another type of interface?  But it's late so I may be remembering it backwards
[12:47] <kiko> I have to finish catching up with commits
[12:47] <sabdfl> kiko: praise was genuine, kidding about the review
[12:47] <sabdfl> i'll put it in the queue, it's nice but nothing essential
[12:47] <sabdfl> and i have a few tests left to add
[12:47] <kiko> and then I will do two days of reviews
[12:47] <kiko> well, one day
[12:47] <sivang> and also, "haha" for the 3,000 [trivial]  lines :-)
[12:47] <kiko> two days is hard because my inbox just goes boom
[12:48] <kiko> but I'll start tomorrow afternoon if possible
[12:48] <sabdfl> kiko: you're a hero for tackling the reviews, but it may be worth figuring out where the bottlenecks in our review team are
[12:49] <kiko> I think rob manages them well -- main bottlenecks are when branches get assigned to me! :)
[12:49] <kiko> (just ask flacoste)
[12:49] <sabdfl> i'm a bit worried about this bradb-flacoste adapter love-fest
[12:49] <sabdfl> bye-bye readability...
[12:50] <sabdfl> "I've got an IFoo adapted to a IBar being passed to an IBaz through a security adapter and something's not working"
[12:50] <sabdfl> help
[12:51] <kiko> I think it depends on where and how it's used
[12:51] <kiko> IBugTarget is something that would clean up some 200 LOC
[12:51] <kiko> which is currently spread around separate classes
[12:52] <kiko> keeping it together would be a maintenence plus
[12:52] <kiko> would need to consider how it's used more carefully though
[12:59] <sivang> going to sleep, night all
[01:18] <sabdfl> night folks
[01:21] <kiko> night
[02:32] <bimberi> hi all, i've committed a fix to bug 55534, yet its importance remains at "Untriaged".  I don't seem to be able to edit that.  Should I be able to?  Does it matter?
[02:32] <Ubugtu> Malone bug 55534 in language-pack-gnome-en ""Select Folders" in en_GB translation should read "Search Folders"" [Untriaged,Fix committed]  http://launchpad.net/bugs/55534
[02:40] <bimberi> ... or should i ask in #ubuntu-bugs ;)
[02:42] <dsas> bimberi: You need to be in the ubuntu-qa team to change the importance.
[02:43] <bimberi> dsas: righto, thanks
[02:43] <dsas> bimberi: As far as I know rosetta commits are automatically imported into the repositories every once in a while.
[02:44] <dsas> bimberi: So there's probably no need to worry :)
[02:45] <bimberi> dsas: kk, thanks again :)
[04:02] <bmonty> is there a way to get an easily parseable version of the information at https://launchpad.net/distros/ubuntu/+archivemirrors?
[04:04] <spiv> bmonty: I don't think so, unfortunately.
[04:04] <bmonty> is the format of the current page likely to change?
[04:04] <bmonty> I have a program that would parse the mirrors list in the wiki and then test them for the fastest one (like apt-spy)
[04:05] <bmonty> I gave up on it because the mirror list format was changing and I had to keep reworking the parsing code
[06:49] <mpool> hi
[06:49] <mpool> could we please have a list of milestones on pages like https://launchpad.net/products/bzr/+bugs
[06:49] <mpool> ?
[06:59] <mpt> Gooooooooooooooooood evening Launchpadders!
[06:59] <ajmitch> evening mpt
[07:03] <mpool> hello mpt!
[07:04] <mpool> where are you now?
[07:10] <sivang> morning!
[10:06] <carlos> morning
[10:09] <ddaa> Good morning.
[10:21] <carlos> stub: hi
[10:21] <stub> hi
[10:22] <carlos> did you have time to review my translation migration branch?
[10:36] <stub> carlos: I need to do the code review do I? There doesn't seem to be a db patch in there.
[10:37] <carlos> stub: the code review has a lot of SQL queries
[10:37] <carlos> in fact most of the patch are raw sql queries
[10:39] <stub> carlos: So when we create a new distro release, we need to insert maybe 10 million new rows into the DB?
[10:40] <carlos> kind of, yes
[10:40] <carlos> it took around 2 hours
[10:40] <carlos> that's why I want a review from you, to see if you can give us more hints to improve its performance
[10:41] <carlos> Steve told us to introduce a small delay between queries so we don't lock the whole database
[10:42] <carlos> it will take more time to complete, but we don't need to close launchpad
[10:42] <carlos> anyway, it will be executed only once every 6 months so I guess another option is to close it while doing the migration
[10:43] <spiv> Without understanding the problem at all, it sounds like the ideal solution would be to not need to insert the 10 million rows at all ;)
[10:44] <spiv> This sort of problem suggests that the data structures could be better.
[10:44] <carlos> spiv: that would mean that any translation in dapper will not be reused in edgy ;-)
[10:45] <carlos> spiv: we have an idea to implement a kind of inheritance
[10:45] <carlos> so we don't need to do that amount of inserts
[10:45] <carlos> but that's not viable in the near future
[10:49] <jamesh> spiv: you borked the "state age" column on the pending-reviews page
[10:49] <jamesh> spiv: should be fixed for the next update though
[10:51] <plaes> Q about the Rosetta's database layout, how are the plural strings stored?
[10:51] <Keybuk> checkrdepends on drescher appears to be broken ... it's exiting with an "unexpected end of file" error from gunzip
[10:51] <spiv> jamesh: oops, thanks.
[10:52] <jamesh> spiv: there is a pickled dictionary to keep track of that info, keyed off the branch URL
[10:52] <Keybuk> oh, ignore me, -ENOCOFFEE
[10:52] <spiv> jamesh: yeah, makes sense.
[10:54] <carlos> plaes: as any other translation with the index it has
[10:54] <carlos> plaes: why?
[10:55] <plaes> carlos: I'm thinking of writing smth on my own ;)
[10:56] <carlos> plaes: we map more or less the same information the .po file format defines + some extra metadata
[10:57] <plaes> so, if there isn't any plural form, then the "msgid_plural" column is just empty?
[10:57] <carlos> no, we use indexes for that
[10:57] <carlos> 0 is singular and 1 is plural
[10:57] <carlos> is much more simple
[10:58] <carlos> is the way translations are handled
[10:58] <plaes> what about languages with 3 plural forms?
[10:59] <carlos> 0, 1, 2
[11:01] <plaes> heh.. It seems that I need to take some "thinking simple" classes :)
[11:01] <plaes> thanks, carlos :D
[11:01] <carlos> plaes: do you really think you need a new project?
[11:02] <carlos> there are some projects already out there with source available
[11:02] <carlos> plaes: np
[11:02] <plaes> carlos: well, I'm not the one who decides.. :(
[11:02] <carlos> I see
[11:03] <plaes> but the work you have done with Rosetta is awesome :)
[11:07] <carlos> plaes: we have already 2 years of development ;-)
[12:05] <carlos> stub: aren't we updating every day staging's database?
[12:05] <stub> carlos: There is an RT job that needs sorting first (603? 605?)
[12:06] <carlos> I see
[12:06] <carlos> ok
[12:06] <carlos> stub: is ok If I merge my translation migration branch?
[12:06] <carlos> or should I wait too ?
[12:06] <stub> To staging? Or to rocketfuel?
[12:06] <carlos> to staging
[12:07] <carlos> I want to do more timings
[12:09] <stub> carlos: Go for i
[12:10] <stub> t
[12:10] <carlos> ok, thanks
[12:10] <stub> If you need a new db, I can push one out but it will take a few hours to load.
[12:10] <carlos> **** Staging will be down in 5 minutes for 5 - 10 minutes ****
[12:10] <carlos> stub: no, I don't need a new database
[12:10] <carlos> thanks
[12:11] <carlos> is just that we are doing some migration testing and I found that the migration from yesterday was still there
[12:11] <carlos> the migration is done, I'm just waiting for the OK of the product maintainer
[12:12] <Yannig> Hello
[12:13] <Yannig> Another dumb question: how is the translation memory organized as far as updating is concerned?
[12:14] <Yannig> Sometimes, I find proposed something I've just translated, great. But it often occurs that something I know I translated weeks ago is not proposed ("yes" or "no" for example)
[12:15] <carlos> Yannig: we only show suggestions that are newer than the translation that is being used
[12:15] <carlos> Yannig: btw, hi :-P
[12:15] <Yannig> Hi carlos :)
[12:16] <Yannig> Yes but I'm just talking about untranslated strings
[12:16] <Yannig> So there should be nothing newer :)
[12:16] <carlos> that's a bug then
[12:17] <Yannig> For example, I'm in front of Thunar translation, string #306, I'm pretty sure "General" was already translated yesterday and nothing proposed
[12:17] <Yannig> (the same for the following one: "Name:"
[12:18] <Yannig> I don't know how to report that kind of bug: I just can't find a rule when it works and when it doesn't :(
[12:18] <carlos> Yannig: https://launchpad.net/products/rosetta/+bug/45196 ?
[12:18] <Ubugtu> Malone bug 45196 in rosetta "Suggestions appear too late" [High,Confirmed]
[12:19] <Yannig> carlos> Let's see :)
[12:20] <Yannig> But some do appear almost at once (I saw it when I translated simultaneously about-ubuntu and about-kubuntu)
[12:20] <carlos> Yannig: is easy to know if it's that bug
[12:20] <Yannig> But it may be that, I'll have a look at it now
[12:21] <carlos> click over the save & continue button
[12:21] <carlos> without adding any translation
[12:21] <carlos> and return to that page
[12:21] <carlos> if you see the suggestions, is the same problem
[12:21] <Yannig> Fair enough, I'll try this next time :)
[12:21] <carlos> ok ;-)
[12:22] <Yannig> carlos> The same :)
[12:23] <carlos> ok
[12:25] <Yannig> Thanks a lot :)
[12:49] <malcc> stub: Ping
[12:49] <stub> yo
[12:49] <malcc> Hi
[12:49] <sabdfl> malcc: commented on the signed-PPA's thing
[12:49] <malcc> We'd like to rollout to drescher including r3855, which had a database permission change
[12:50] <sabdfl> malcc: main thing that will help us tomorrow is if you have a good visual representation of the Soyuz data model, in detail, showing all tables and columns
[12:53] <malcc> sabdfl: I'll do my best; we might have to settle for a good visual representation showing the main columns, and a messy one we can refer back to for the full column list
[12:53] <sabdfl> ok, thanks
[12:55] <Yannig> And btw, if someone knows how my Karma was multiplied by 10 during my holidays (without any translation from me)... :D
[01:18] <mdke> Yannig: oh yeah, karma seems to have gone up a lot. It is pretty unpredictable
[01:18] <Yannig> Mine or all Karmas?
[01:18] <mdke> all, I think
[01:21] <Yannig> OK
[01:31] <carlos> Yannig, mdke: I guess it's because all my karma was removed
[01:31] <Yannig> carlos> It's not removed: you have more than 600,000
[01:32] <carlos> I think we have a fixed amount of karma to share between users and all my karma was removed, we split it between all accounts
[01:32] <carlos> Yannig: sorry, I'm talking about my karma for translations
[01:33] <Yannig> OK
[01:33] <carlos> I got a bunch of it because some oo.org work
[01:33] <carlos> and we removed it a couple of weeks ago
[01:34] <carlos> Yannig: look at the karma like stock options ;-)
[01:34] <carlos> they change every day up and down
[01:34] <carlos> depending on the 'market' :-)
[01:35] <Yannig> :D
[01:35] <carlos> see you later!
[01:42] <danilos> bzr ate all of my memory getting my system to a crawl, will fix for bug 50290 be in dapper soon?
[01:42] <Ubugtu> Malone bug 50290 in bzr "Creating a branch in a repository chews up huge amounts of memory" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/50290
[03:44] <kiko> SURF
[03:44] <kiko> IS
[03:44] <kiko> UP
[03:44] <lucasvo> surf?
[03:45] <kiko> how's it going up north
[03:46] <kiko> hey matsubara
[03:46] <kiko> how's london
[03:48] <matsubara> hey kiko, sunny day!
[03:48] <kiko> wow, that's a first :)
[03:48] <mdke> 22 degrees of sunny
[03:54] <jamesh> kiko: "not a very fast box"?
[03:58] <kiko> jamesh, <wink>
[03:58] <kiko> stub!
[03:58] <kiko> how goes it up north
[03:58] <stub> Thrilling as always
[03:58] <kiko> yes london is the edge
[03:59] <kiko> stub, did you manage to finish the bug cleanup?
[03:59] <kiko> oh I see one bug left
[03:59] <kiko> and one source package name
[04:00] <kiko> cool
[04:07] <kiko> stub, is there a way to discover what's holding on to a source package name reference?
[04:09] <jamesh> kiko: we've updated the way the oops summaries group timeout errors
[04:10] <kiko> jamesh, ah, really? tell me
[04:10] <jamesh> kiko: it now groups them by the SQL statement pattern with the highest cumulative runtime
[04:10] <jamesh> kiko: previously it was grouping by exception name/value, which was essentially by the last statement run
[04:10] <jamesh> (which might not have been the problem statement)
[04:10] <kiko> right, that's quite common
[04:10] <kiko> great idea
[04:15] <kiko> stub, ping?
[04:15] <SteveA> kiko: hi
[04:15] <kiko> hello SteveA
[04:15] <kiko> how's the sun
[04:17] <SteveA> apparently somewhere outside.  it looks nice outside
[04:17] <SteveA> it casts laser-sharp light on the proceedings
[04:18] <kiko> SteveA, does stub not want to talk to me? ;)
[04:18] <SteveA> stub is kinda busy
[04:18] <SteveA> what's up?
[04:18] <kiko> read up
[04:19] <SteveA> summarize
[04:20] <sivang_> re folks
[04:21] <kiko> SteveA, ffs. there's still a bug needing cleaning up.
[04:22] <sivang> flacoste: morning/afternoon :)
[04:22] <flacoste> sivang: morning!
[04:22] <SteveA> kiko: the database package cleanup stuff?
[04:22] <kiko> SteveA, yes.
[04:22] <sivang> flacoste: how are you?
[04:22] <SteveA> kiko: I'll interrupt stu soon
 oh I see one bug left
 and one source package name
 stub, is there a way to discover what's holding on to a source package name reference?
[04:23] <kiko> SteveA, thanks.
[04:23] <flacoste> sivang: fine, i'm enjoying the speed up brought by my new laptop
[04:23] <sivang> flacoste: oh nice, what kind of a machine is it? (/me has T43p)
[04:25] <flacoste> it is bigger but a lot more performant
[04:25] <sivang> oh, cool. I should also extend to 2G ram, currently I have 1GB it starts to not be enough...
[04:25] <sivang> I just wish I had an nVidia GFX chipset, rathen then ATI
[04:27] <stub> kiko: Getting there
[04:27] <kiko> thanks stub
[04:34] <sivang> flacoste: so anyways, you've started explaining something to me yesterday, and as you offered, I'm highly interested to hear more, and try to solve at least partially, the bug from yesterday. Hm.., seems salagdo's commment sheds more light on this as a system wide issue..
[04:34] <sivang> malone #4576
[04:34] <Ubugtu> Malone bug 4576 in launchpad "It's not easy to attach a custom error message to a field that uses a Choice widget and a vocabulary" [Medium,Confirmed]  http://launchpad.net/bugs/4576
[04:37] <flacoste> sivang: salgado is right, it is a system wide issue
[04:40] <sivang> flacoste: how hard do you thik it will be to fix it?
[04:42] <flacoste> sivang: it won't be trivial, let's say challenging :-)
[04:42] <kiko> carlos, ping?
[04:42] <carlos> kiko: pong
[04:43] <kiko> carlos, can you explain to me what bug 35631 was about?
[04:43] <Ubugtu> Malone bug 35631 in rosetta "Karma handling on Rosetta is broken" [High,Fix released]  http://launchpad.net/bugs/35631
[04:43] <kiko> the description is very unclear
[04:43] <flacoste> sivang: I think we are already using a custom widget there, that would be the place to fix it
[04:43] <carlos> kiko: that's already fixed ....
[04:43] <kiko> carlos, that's why I said "was" about.
[04:44] <carlos> kiko: hmmm the description is good enough, isn't it?
[04:44] <carlos> in fact that was exactly what I fixed ;-)
[04:44] <kiko> carlos, no, it's not. can you explain what the bug was about?
[04:44] <kiko> and how we fixed it?
[04:44] <carlos> we were giving karma to people that don't have an active launchpad account
[04:44] <kiko> ah.
[04:44] <carlos> and that weren't using launchpad to do translations
[04:45] <flacoste> bradb: ping
[04:45] <sivang> flacoste: I see, could you please direct me to find it's implementation and/or example code where we already did that?
[04:45] <kiko> so now we do not assign karma to people without valid accounts, ever?
[04:45] <bradb> flacoste: pong
[04:45] <carlos> kiko: as a side effect, yes
[04:45] <kiko> carlos, side effect?
[04:45] <carlos> kiko: we give karma only to people that use rosetta ui or the upload form as a user upload
[04:45] <carlos> and to do that, they should have valid accounts
[04:46] <carlos> so it's a side effect ;-)
[04:46] <flacoste> bradb: what is the widget used to select the source package (in bug task)?
[04:46] <kiko> carlos, ah. so we no longer assign karma for imports, is that it?
[04:46] <kiko> I'm certainly confused
[04:46] <bradb> flacoste: ISinglePopupWidget. your vocab has to implement IHugeVocabulary.
[04:46] <carlos> kiko: we do, but only when the translations are not comming from upstream
[04:47] <carlos> so if someone does an offline translation and uploads it, we give karma
[04:47] <carlos> but the automatic imports doesn't give karma
[04:47] <kiko> carlos, I /still/ don't understand :-(
[04:47] <kiko> either this is very complicated or I am very dull
[04:47] <flacoste> sivang: so the fix should go into canonical.widgets.popup.SinglePopupWidget
[04:48] <carlos> kiko: Is not complicated at all....
[04:48] <carlos> we have two sources for translations:
[04:49] <carlos> - The ones comming from upstream.
[04:49] <flacoste> sivang: you could override the _toFieldValue method (from SingleDataHelper) to raise a subclass of ConversionError instead of the generic one
[04:49] <carlos> - The ones translated using Rosetta (either using the web UI or offline translations and later uploads)
[04:49] <flacoste> sivang: after that, you can define a view for that specific error type which would display the error message
[04:50] <kiko> carlos, what do you mean by "coming from upstream"?
[04:50] <carlos> kiko: dude... do you really know how Rosetta works?
[04:50] <mdke> those upstreams that don't use rosetta
[04:50] <carlos> kiko: I think that's the problem here...
[04:50] <carlos> kiko: any translation that come directly from source tarballs
[04:51] <carlos> and that upstream already has (GNOME, KDE, etc...)
[04:51] <kiko> carlos, oh. well, that's not "upstream" to me.
[04:51] <carlos> the ones that doesn't come from upstream are the ones new that we get from Rosetta users
[04:51] <carlos> kiko: that's upstream to me...
[04:51] <kiko> carlos, surely you mean package imports?
[04:51] <carlos> no
[04:51] <carlos> that's just a small portion of upstream
[04:51] <carlos> well...
[04:52] <carlos> it's a big portion now
[04:52] <kiko> hmmm?
[04:52] <carlos> but shouldn't
[04:52] <carlos> when we start importing GNOME's CVS/SVN or KDE one
[04:52] <carlos> directly
[04:52] <kiko> do we import any upstream tarballs directly?
[04:52] <kiko> I thought we only imported them via the buildds
[04:52] <carlos> kiko: yes, all products with translations, for instance
[04:52] <kiko> i.e. via packages
[04:53] <carlos> not automatically, but we do such imports
[04:53] <kiko> carlos, oh. where do we pull them from?
[04:53] <carlos> kiko: atm, the maintainer upload them manually
[04:53] <kiko> when the end-user requests an import, you mean?
[04:53] <carlos> right
[04:53] <kiko> hmmm
 - The ones translated using Rosetta (either using the web UI or offline translations and later uploads)
[04:53] <kiko> and that's different from what you wrote there ^ ?
[04:54] <kiko> ah, I think I see
[04:54] <carlos> kiko: when you do an upload
[04:54] <kiko> these people are uploading on a single pofile
[04:54] <carlos> right
[04:54] <carlos> and that they got from Rosetta
[04:54] <carlos> and they update offline
[04:54] <kiko> whereas the maintainer uploads a tarball with multiple pofiles and potemplate.
[04:54] <kiko> I see
[04:54] <carlos> that already have and that will be released with next tarball rollout that they release
[04:55] <kiko> I see
[04:55] <kiko> so I can see more than two ways of getting translations into rosetta, though:
[04:55] <kiko> 1. end-user translates using the web application
[04:55] <kiko> 2. end-user downloads pofile, translates and uploads
[04:56] <kiko> 3. maintainer uploads tarball with template and translations
[04:56] <kiko> 4. buildd assembly generates a tarball with template and translations
[04:56] <kiko> 3 affects only upstream translations and 4 affects only distribution translations
[04:56] <kiko> carlos, is that correct?
[04:56] <carlos> yeah, you can split them that way too
[04:57] <kiko> ok so far.
[04:57] <carlos> 3 and 4 are handled the same way
[04:57] <carlos> 1 and 2 are handled the same way
[04:57] <kiko> well except that they go to different targets.
[04:57] <kiko> so which of those 4 cases assign karma?
[04:57] <carlos> 1 and 2
[04:58] <kiko> I see.
[04:58] <kiko> thanks, I'll update the bug.
[04:58] <carlos> kiko: also, take a look to the doctest
[04:58] <carlos> I tried to document it
[04:59] <stub> kiko: Email
[04:59] <carlos> and feel free to improve it if you think it's not good enough
[04:59] <carlos> kiko: rosetta-karma.txt
[04:59] <doko> carlos!
[05:00] <carlos> doko: !
[05:00] <carlos> I didn't forget you
[05:00] <carlos> don't worry
[05:00] <carlos> ;-)
[05:00] <carlos> I'm just trying to handle all things I left open before my vacations
[05:01] <kiko> stub, there is still one bug left.
[05:01] <kiko> (as I said above)
[05:01] <kiko> stub, ah, I think I see what happened -- somebody added it since yesterday :-(
[05:01] <stub> Yup
[05:02] <kiko> stub, can you nuke it too?
[05:02] <stub> Yes. As can you I think ;)
[05:03] <kiko> stub, the source package name?
[05:03] <kiko> I don't have root!
[05:03] <stub> kiko: You are a launchpad admin, no?
[05:03] <stub> It needs to be done though the web ui
[05:03] <kiko> stub, I am, but AFAIK we can't delete source package names
[05:04] <kiko> stub, no, this bug will require a DELETE
[05:04] <stub> So I will need to run that delete statement from the bug (?)
[05:04] <kiko> if you look at it
[05:04] <kiko> yeah
[05:04] <kiko> bug 48263
[05:04] <Ubugtu> Malone bug 48263 in linux-image-2.6.15-23-386 "[regression]  Wired ethernet (VIA VT6102 Rhine II) and Wireless (RaLink 2500) no longer work under 6.06 (needs acpi=noirq blacklisting)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/48263
[05:04] <stub> Yup. One row nuked.
[05:05] <kiko> ROCK ON!
[05:05] <kiko> whew
[05:05] <kiko> only 18 SPNs left to nuke
[05:05] <kiko> stub, you know that query you did that said what tables referenced what?
[05:06] <stub> I suspect I should nuke all the supportcontacts to invalid sourcepackages. yes?
[05:06] <kiko> stub, is that something I can do as well?
[05:06] <kiko> stub, yes.
[05:07] <stub> kiko: https://sodium.ubuntu.com/~andrew/paste/fileJPSRgi.html
[05:08] <kiko> stub, I nuked the ticket link there as well
[05:08] <kiko> stub, so feel free to nuke those contacts
[05:08] <kiko> and then the remaining SPNs
[05:09] <stub> I've nuked the contacts
[05:10] <kiko> stub, and now, just 17 SPNs remaining
[05:11] <kiko> kill those and we can all go home!
[05:11] <malcc> kiko: I hope you mean just 17 bad ones remaining, otherwise Ubuntu just got a lot smaller
[05:11] <stub> kiko: All done
[05:11] <kiko> malcc, oops, NOT THAT BUTTON!
[05:11] <jamesh> that should make it a lot quicker to install
[05:12] <kiko> jamesh, even quicker on those fast boxes you have in australia
[05:12] <kiko> stub, thanks a million, owe you 10 beers
[05:12] <jamesh> kiko: the fast box is in London
[05:12] <kiko> stub, is it possible to produce a database constraint that requires a sourcepackagerelease for a source package name?
[05:13] <kiko> and malcc, cprov-away: would soyuz work if we had something like that?
[05:14] <malcc> kiko: We'd need the constraint deferred until commit time, as you can't have a sourcepackagerelease without a sourcepackagename - we'd get a chicken and egg job
[05:14] <kiko> right. hmmm.
[05:14] <malcc> Do we do deferred constraints in these parts?
[05:15] <stub> I think we can make an INITIALLY DEFERRED foreign key constraint
[05:15] <stub> malcc: Not yet - we haven't needed them yet.
[05:16] <stub> kiko: Please file a bug and assign it to me or it will get lost in the sprint
[05:16] <malcc> stub, kiko: If we have an initally deferred foreign key constraint, I'm pretty sure Soyuz will work; I can't see any reason we'd be creating the spn in a different transaction than the spr
[05:16] <stub> malcc: If we care, the test suite should pick it up anyway ;)
[05:16] <kiko> malcc, there is UI to create standalone SPNs, but that should also go away because it can cause pain (as we've seen).
[05:17] <malcc> kiko: Cool, as a side effect we'll break some UI we don't want :)
[05:17] <sivang> flacoste: thanks, I'll try to combine this explenation with some reading of the code there.
[05:18] <kiko> heh
[05:18] <flacoste> sivang: you'll also need to find a way for client of the widget to customize the error message: that could be an attribute set on the widget on initialization
[05:21] <sivang> flacoste: so the attribute will be used to determine if to react to the error in a webish way (form notification) email , or xml rpc error etc?
[05:22] <flacoste> sivang: no the attribute would be more like the vocabulary description: what values are expected
[05:22] <sivang> flacoste: ah , I see.
[05:23] <flacoste> sivang: otherwise the widget will still be limited to a generic 'Value not in vocabulary' message
[05:24] <sivang> flacoste: ah cool, so that attribute will be set up with the proper error message and each client (bugtask, support etc) will set it accordignly
[05:24] <flacoste> sivang: yes, something like that
[06:11] <kiko> BjornT, ping?
[06:12] <BjornT> hi kiko
[06:12] <kiko> how's it going BjornT
[06:12] <kiko> and what are you up to this week
[06:14] <BjornT> quite good, thanks. currently i'm working on finishing up the bug tags implementation, and if you give the final ok, i was planning to fix bug 30225.
[06:14] <Ubugtu> Malone bug 30225 in malone "Attach files via email" [High,Confirmed]  http://launchpad.net/bugs/30225
[06:15] <salgado> hey kiko! are you going to have some time for that shipit review today?
[06:16] <kiko> BjornT, ah great -- see my email to mpt (about to go out) on the subject of tags then. Sounds good. I just want to make sure we are on track for the upstream bug workflow implementation!
[06:16] <kiko> salgado, in the end of the afternoon possibly
[06:17] <flacoste> salgado: kiko needs to finish my reviews first ;-)
[06:20] <laszlok_work> jordi: ping
[06:21] <BjornT> kiko: ok, i should be able to start doing some work on bug forwarding workflow next week.
[06:23] <kiko> BjornT, cool.
[06:23] <laszlok_work> carlos: ping
[06:24] <kiko> BjornT, read my email -- suggestions in there for tags work! :)
[06:25] <BjornT> kiko-fud: ok, reading it now :)
[06:35] <flacoste> woohoo, running a page test went from 120s to 15s!!!
[07:13] <LarstiQ> flacoste-lunch: nice :)
[07:14] <kiko> flacoste-lunch, how?
[07:19] <carlos> laszlok: pong
[07:39] <flacoste> kiko: how I manage to reduce the pagetest run from 120s to 15s: easy: laptop upgrade!
[07:40] <kiko> heh
[07:49] <bradb> kiko: Will you have a chance to look at the RM UI?
[07:49] <kiko> bradb, yeah, as soon as I catch up with reports)
[07:49] <bradb> ok
[08:16] <flacoste> anyone has an idea why i'm not receiving pqm's replies?
[08:17] <flacoste> my requests get in the queue, but I don't get any reply back once they are out
[08:17] <kiko> hey jamesh
[08:19] <flacoste> even weirder, if I send a bogus request - i do get a reply back
[08:20] <jamesh> kiko: hi
[08:20] <flacoste> (this seems to exclude a mail communication problem)
[08:20] <jamesh> bradb: looks like mdz tripped over the "include attachment" checkbox
[08:20] <kiko> jamesh, what was the last bug ID we imported from ubuntu?
[08:21] <jamesh> kiko: from the main import, or overall?
[08:22] <kiko> jamesh, from the ubuntu bugzilla import
[08:22] <flacoste> kiko: who is responsible for pqm?
[08:22] <jamesh> we missed a few bugs in the first import and had to import them afterwards
[08:22] <kiko> flacoste, lifeless and stub mainly
[08:22] <stub> lifeless is resposible, I'm irresposible
[08:23] <flacoste> i'll mail robert then
[08:25] <bradb> jamesh: context?
[08:25] <kiko> ddaa, ping?
[08:26] <jamesh> bradb: https://launchpad.net/products/malone/+bug/55698
[08:26] <Ubugtu> Malone bug 55698 in malone "Attachment is silently ignored if description is left blank" [Untriaged,Unconfirmed]
[08:26] <mdz> jamesh: approximately, though, what's the bug number after which it's a safe assumption that the bug didn't come from bugzilla?
[08:26] <mdz> it's ok if there are a few stragglers
[08:26] <jamesh> kiko: from the look of it, bug 36280
[08:26] <Ubugtu> Malone bug 36280 in gtk+2.0 "gnome-background-properties crashes on selecting a directory to add new file" [Medium,Fix released]  http://launchpad.net/bugs/36280
[08:27] <kiko> jamesh, can you grok what this landing means:
[08:27] <kiko>   [r=BjornT]  importd CVS recheckout preserves Catalog.sqlite
[08:27] <kiko> or BjornT
[08:27] <jamesh> there are twobugs with higher numbers with ubuntu bugzilla bug watches but they look like they were added manually
[08:28] <jamesh> mdz: so anything higher than 36280 shouldn't be a bugzilla bug
[08:28] <jamesh> (originally)
[08:28] <bradb> jamesh: ah, strange, the cb is auto-checked for me. thanks for the heads up.
[08:29] <jamesh> bradb: it is when the file entry field loses focus, but hitting enter in that field can submit the form
[08:29] <jamesh> bradb: in which case the JS doesn't kick in
[08:30] <jamesh> if the checkbox wasn't there, we wouldn't have a problem :)
[08:30] <kiko> we could ignore the checkbox
[08:30] <kiko> and we could use JS to enable/disable the fields
[08:31] <kiko> jamesh, the problem is that the lack of checkbox can communicate a "you need to fill  these fields in" model to the user.
[08:31] <jamesh> kiko: really?
[08:31] <kiko> jamesh, and we don't really want bogus attachments..
[08:32] <jamesh> kiko: how about using a collapsible field set?
[08:32] <kiko> jamesh, well, yeah. put 4 fields in the for the end-user to fill in and part of the population will feel obligated to fill it in.
[08:32] <kiko> jamesh, that might be a simple solution as well
[08:32] <kiko> perhaps a better one
[08:32] <jamesh> nothing extra sent back to the server, and they'll either see the colleciton of fields together, or none of them at all
[08:32] <kiko> I don't know how well that would work given the fact that we already have a disclosure triangle there
[08:32] <kiko> it's mostly a user perception thing
[08:33] <jamesh> the JS should be able to handle it
[08:33] <kiko> well I mean end-user wise
[08:33] <kiko> two collapsed sections
[08:33] <kiko> where do you put the button?
[08:33] <jamesh> where the field set is currently
[08:34] <kiko> jamesh, the fieldset is currently encapsulated by the expandable area for commenting, though
[08:34] <kiko> my meaning is: will you have nested disclosure triangles? or something else?
[08:36] <bradb> we could also just fix the auto-select behaviour to also select the cb when a filename is manually entered
[08:36] <kiko> bradb, that's easy to do you know
[08:37] <bradb> yeah, i'll fix it now
[08:37] <bradb> unless somebody screams
[08:37] <jamesh> kiko: nested disclosure triangles.
[08:37] <kiko> ah.
[08:37] <kiko> I don't know if I like that very much :-P
[08:37] <kiko> jamesh, did you see my other question above?
[08:37] <kiko>   [r=BjornT]  importd CVS recheckout preserves Catalog.sqlite
[08:38] <kiko> do you know what that was about?
[08:39] <jamesh> kiko: I can guess about it.
[08:39] <kiko> jamesh, oh! please do
[08:40] <jamesh> kiko: cscvs maintains a catalogue of the changesets it has previously imported from the CVS module
[08:40] <kiko> jamesh, okay so far
[08:40] <jamesh> it needs this because CVS doesn't have tree-wide revisions, and due to race conditions you could get different results if you run imports at two different times
[08:40] <jamesh> (if you are doing an import while a checkin is in progress)
[08:41] <kiko> I see.
[08:41] <jamesh> so the catalogue is important when updating the import
[08:41] <kiko> so does this mean that the catalogue is preserved when doing an update, or what is the "recheckout" part there?
[08:42] <jamesh> I guess "recheckout" is something to get a CVS clean working copy, and you want to make sure the cscvs catalogue isn't lost
[08:42] <jamesh> BjornT might be able to give a better answer, since it appears he reviewed it
[08:42] <kiko> yeah, but he's awol and I want to finish this report. thanks!
[08:46] <BjornT> jamesh, kiko: i forgot exactly when you do a 'recheckout', but it could be when the cvs location changes. then you need to checkout the tree again, and you want to make sure that your changeset catalogue remains the same. i'm not sure, though, it was a while since i reviewed that branch.
[08:46] <kiko> BjornT, that's fine. thanks!
[08:47] <solleth> hello
[08:47] <mdz> jamesh: thanks
[08:48] <solleth> hello
[08:48] <solleth> can i request
[08:49] <bradb> mdz: for bug 55698, did you manually type the filename in the field?
[08:49] <kiko> request?
[08:49] <kiko> bradb, no, I think he selected a filename and then just typed enter -- never leaving the field.
[08:51] <bradb> kiko: i can't reproduce what i think you mean. what key sequence are you describing that will reproduce this?
[08:52] <bradb> in epiphany, FF, and Safari, the cb is selected as soon as a choose a file from the File Upload dialog
[08:52] <kiko> bradb, click on button. select file. press enter.
[08:53] <bradb> wfm
[08:53] <kiko> mdz?
[08:59] <mdz> bradb: yes
[08:59] <mdz> I typed it in
[08:59] <bradb> kiko: so, my change fixes the problem mdz describes
[08:59] <kiko> mdz, I don't think typing in the filename ever works on firefox, but ok.
[09:00] <kiko> bradb, so r=kiko, update bug with information.
[09:00] <mdz> kiko: sure it does; I did it the second time too
[09:00] <bradb> kiko: thanks
[09:00] <mdz> type in filename, tab to description(checkbox gets checked here), press enter
[09:00] <mdz> bug #55695
[09:00] <Ubugtu> Malone bug 55695 in linux-source-2.6.17 "BUG when inserting PCMCIA flash adapter" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55695
[09:00] <mdz> attachment seems to have arrived intact
[09:29] <solleth> hallo
[09:29] <sebastienserre> bonsoir ;-)
[09:39] <solleth> can i ask something bro
[09:39] <solleth> please
[09:40] <sebastienserre> bro ?.
[09:40] <sebastienserre> i don't know what its means !
[09:40] <sebastienserre> i'm sory, i'm a newbie here ..
[09:40] <solleth> brother
[09:40] <bradb> sebastienserre: bro == mec
[09:41] <solleth> where i can get linux cd
[09:41] <solleth> for free
[09:42] <bradb> solleth: https://shipit.ubuntu.com/
[09:45] <solleth> wait i see
[09:45] <solleth> thats for ubuntu
[09:46] <solleth> i looking for sunOS
[09:46] <solleth> :(
[09:47] <solleth> please help me Bradb
[09:49] <ddaa> kiko: importd does recheckout when
[09:49] <ddaa> changes are detected in the cvs tree (should not ever happen)
[09:49] <kiko> solleth, SunOS is not linux, and you are not in the right channel.
[09:50] <ddaa> or when the cvsroot changes
[09:50] <ddaa> that fix was prompted by the sourceforge cvsroot mass change
[09:50] <ddaa> although it was needed anyway
[09:51] <ddaa> kiko: do you have enough information now?
[09:51] <solleth> how about suse
[09:51] <kiko> ddaa, yes.
[09:51] <kiko> solleth, you are in the wrong channel
[09:51] <kiko> solleth, try #suse
[09:51] <solleth> thanks you
[09:51] <ddaa> kiko: that's pretty old stuff, like a couple of months ago
[09:52] <kiko> ddaa, yeah, from june.
[09:52] <kiko> jamesh, tell me about this formlib-based-launchpadformview?
[09:53] <bradb> that sounds like a hint that we should start using formlib
[09:53] <kiko> heh
[09:55] <ddaa> kiko: in short, that patch was needed to preserve correctness when a cvs repo we are importing from migrates
[09:55] <kiko> ddaa, understood. I fudget the line a bit but you might find it interesting even so
[09:55] <ddaa> I always read the highlights and the Bazaar section of your report with great interest
[09:56] <ddaa> as I expect it's the primary source of information about launchpad progress for sabdfl
[09:56] <ddaa> and other top mgmt
[09:57] <kiko> ddaa, one thing that would be a major help to me would be slightly more end-user-oriented merge messages
[09:57] <kiko> I know how you feel about large ones
[09:57] <ddaa> I dislike long ones on multiple lines
[09:57] <ddaa> on a single line, I mean
[09:57] <kiko> but it really would help to have an idea of what the end-user could expect from that landing -- or just text that made it easier for me to add it to the report
[09:58] <ddaa> yeah, I guess i should look at sending multi-line commit messages to pqm
[09:59] <kiko> it will help me and you'll end up with better feedback as a result
[09:59] <ddaa> kiko: but more often than not, in my work, it's hard to give a short summary of what the patch does to the user
[10:00] <ddaa> I'll try to think of you the next time I use pqm-submit
[10:02] <kiko> thanks
[10:22] <jamesh> kiko: the c/l/doc/launchpadform.txt file describes how to use the new form
[10:22] <kiko> jamesh, is this rearranging form layout as well?
[10:23] <jamesh> kiko: it can be used in pretty much all cases GeneralFormView is being used, and can replace the edit and add form views
[10:23] <jamesh> kiko: we haven't changed the appearance of the forms
[10:24] <kiko> jamesh, ohhhh. what about the FormLayout spec?
[10:26] <jamesh> kiko: I think that kind of thing will be addressed later
[10:26] <flacoste> jamesh: what's the advantage for using LaunchpadViewForm over formlib directly?
[10:27] <jamesh> kiko: there are plans to use new widgets eventually
[10:27] <jamesh> flacoste: it fits in with our existing view base class
[10:27] <kiko> jamesh, that spec was to do with the layout of fields on the form..
[10:28] <jamesh> flacoste: you can look at formlib as a construction kit for implementing view classes + a few sample view classes
[10:29] <jamesh> flacoste: LaunchpadFormView is just integrating formlib with LaunchpadView, and make it not too difficult to migrate existing code over
[10:29] <flacoste> jamesh: yes, but I don't see how the LaunchpadViewForm simplify things over formlib
[10:29] <jamesh> flacoste: also, it should make it possible to add some interesting features to all forms later on
[10:29] <flacoste> jamesh: ok, migration seems a valid point
[10:30] <jamesh> e.g. on-the-fly validation
[10:31] <jamesh> kiko: sure.  The stuff I landed is mainly infrastructure, so hasn't addressed the FormLayout spec yet.
[10:31] <kiko> yeah.
[10:31] <flacoste> jamesh: what would be on-the-fly validation? there is already automatic validation in formlib
[10:31] <jamesh> flacoste: validation without hitting the submit button
[10:31] <flacoste> jamesh: that would nice!
[10:35] <BjornT> flacoste: one thing to consider also, is that we'll probably move away from the current formlib some time, in order to switch to a better widget framework. that will be much easier to do if all code uses the same base class.
[10:44] <jamesh> kiko: for what it is worth, the new form base class does let you customise the submit button text
[10:45] <jamesh> or easily handle multiple submit buttons
[10:46] <laszlok> carlos: ping
[10:47] <salgado> jamesh, is it possible to disable some of these submit buttons conditionally?
[10:47] <kiko> jamesh, and does it fix the tab ordering as well?
[10:49] <jamesh> kiko: not in the initial landing. The sketch in the FormLayout spec is close to what I was considering
[10:52] <kiko> jamesh, ah, ok.
[10:55] <flacoste> salgado: should be, that is part of formlib: you can put a condition on every button
[10:56] <salgado> flacoste, hmmm. I asked because the buttons are created with a decorator, so I was wondering how to do it
[10:56] <flacoste> salgado: @form.action(_('Label'), condition='name_of_condition_method')
[10:57] <salgado> ah, cool!
[10:57] <flacoste> salgado: other keywords are 'success' (method to invoke when the validation succeeded), 'failure' (method to invoke when the validation failed) and 'validate' (custom validation method)
[10:58] <flacoste> salgado: beware though that there is a bug with the 'failure' parameter: you can't use a method name, you have to pass the reference directly
[10:58] <flacoste> flacoste: that is zope issue 573
[10:59] <salgado> only with the failure parameter? weird...
[10:59] <jamesh> flacoste: we're using @action() directly, so that should work fine here.
[10:59] <jamesh> the condition bit, that is
[11:00] <flacoste> salgado: it's because of the parameters required by the failure handler, that issue is fixed in 3.3.0b1 and 3.2.1
[11:02] <flacoste> salgado: there is a little gotcha with the condition, it is invoked before validation and as such it not only remove the action from rendering, it also prevents the action from being considered as submitted
[11:07] <flacoste> bradb: does IBugTarget.searchTasks uniquefy its results based on bugs? or should the client do that?
[11:08] <flacoste> bradb: I mean, if I do a text search and there are multiple bug tasks on the same bug will all bug tasks be returned?
[11:08] <bradb> flacoste: yes
[11:09] <bradb> kiko: https://chinstrap.canonical.com/~bradb/upstream_status.png
[11:09] <kiko> bradb, checkboxes?
[11:09] <flacoste> bradb: is there an existing way to just get the bugs?
[11:09] <kiko> flacoste, yes, all bug tasks will be returned, but it is likely that you want that anyway.
[11:10] <kiko> flacoste, I mean, the bug doesn't have a lot of interesting information attached to it.
[11:10] <bradb> flacoste: no. why do you want just bugs?
[11:10] <bradb> kiko: yeah, i think cb's might be easier to understand
[11:10] <flacoste> kiko, bradb: IBugLinkTarget links to bugs not bugtasks, so no reason to present the same bug multiple time in the selection list
[11:11] <bradb> kiko: and more flexible
[11:11] <kiko> bradb, s/that have been/already/ ?
[11:12] <bradb> kiko: right. maybe just "Show bugs fixed upstream" and "Show bugs not reported as affecting upstream" too?
[11:13] <bradb> not report as, or not know to
[11:13] <bradb> not known to
[11:13] <kiko> bradb, yeah, maybe less text will be less daunting
[11:13] <kiko> (I find those options long!)
[11:13] <bradb> me too
[11:14] <kiko> bradb, have an idea for a person whose account is not enabled yet?
[11:14] <kiko> maybe an empty or faint outline of our regular ninja icon?
[11:14] <bradb> kiko: an idea for what aspect of that problem?
[11:15] <kiko> bradb, I would like a special icon to indicate somebody who doesn't have an active account
[11:15] <kiko> essentially
[11:15] <kiko> the main issue is that that person will not get emailed
[11:15] <matsubara> what's the ninja icon?
[11:15] <kiko> so maybe an email with a slash icon
[11:15] <kiko> matsubara, our current person icn
[11:15] <matsubara> the little guy without eyes?
[11:16] <kiko> yeah.
[11:16] <kiko> ninjas have no eyes
[11:16] <bradb> right, that's hard to communicate in an icon
[11:17] <flacoste> bradb: is ILaunchBag.user the right thing to pass as user parameter to BugTaskSearchParams? i.e. is it None when the user not logged in?
[11:18] <bradb> kiko: https://chinstrap.canonical.com/~bradb/upstream_status.png
[11:19] <bradb> flacoste: docstrings dude! :)
[11:19] <bradb>       user is an object that provides IPerson, and represents the
[11:19] <bradb>       person performing the query (which is important to know for, for
[11:19] <bradb>       example, privacy-aware results.) If user is None, the search
[11:19] <bradb>       will be filtered to only consider public bugs.
[11:20] <bradb> flacoste: and it's a required arg, to ensure you don't accidentally forget it
[11:20] <flacoste> bradb: my question was more about: is ILaunchpad.user = None when the user isn't logged in
[11:20] <bradb> flacoste: in a view, you should pass self.user
[11:21] <flacoste> bradb: thnx, that answers my question
[11:22] <bradb> np
[11:46] <lifeless> flacoste: 'devpad.canonical.com' please, not 'devpad'
[11:47] <flacoste> lifeless: yes, i changed that and it worked. but why didn't i get any message?
[11:48] <lifeless> you tripped an unhandled exception, which I've added to my to-handle list
[11:49] <flacoste> lifeless: nice to know :-) also do you think it would be possible for PQM to send in the reply the revision number that was commited with the merge?
[11:50] <lifeless> please do
[11:50] <flacoste> lifeless: in bazaar or launchpad?
[11:50] <lifeless> are you subscribed to the commits list ?
[11:50] <lifeless> pqm has its own product 'pqm'
[11:50] <flacoste> lifeless: there is a commit list?
[11:51] <lifeless> heck yes
[11:53] <lifeless> arch-commits@l.c.c


[01:05] <Alexion> arraybolt3: I meant the speed at which the wifi is connected
[01:05] <Alexion> like 74Mbps, 100Mbps, 300Mbps etc.
[01:34] <arraybolt3> Alexion: Oh. I think you can do that, don't remember how though. Hold on one moment...
[01:35] <arraybolt3> Alexion: Right-click on the network icon in the system tray, and then click "Connection information". This works on Lubuntu 22.04.1.
[01:36] <arraybolt3> (It appears to list the speed in Kb/s though >_< which may be a bit hard to read.)
[01:43] <Alexion> yes, that shows the current transfer speed, but I don't want that, I'm looking for the rate at which it is connected
[01:43] <Alexion> and I found the solution
[01:43] <Alexion> sudo iw dev wlan0 link
[01:43] <Alexion> replace wlan0 with the name of the wifi card
[01:43] <Alexion> in my case, it says 54Mbps
[01:52] <Alexion> thank you for your support
[14:20] <bperraud> hey everyone


[02:09] <Brainstorm> Updates for Bangladesh: +173 cases, +4603 tests since a day ago
[14:05] <Brainstorm> Updates for Bangladesh: +178 cases, +1 deaths since 11 hours ago


[00:12] <slangasek> Laney: hi, do you know how /usr/lib/x86_64-linux-gnu/libproxy/0.4.7/pxgsettings gets launched?  I happened to be looking at my process list and found 13 instances of this thing running... and the package doesn't seem to ship any dbus service definition?
[00:17] <cjwatson> I have three of them, which 'ps xf' show to be descended from unity-scope-video-remote, unity-shopping-daemon, and unity-lens-photos
[00:17] <cjwatson> also paired "sh -c" processes indicating that the parent processes are lazily using some equivalent of system() rather than a direct execve
[00:18] <cjwatson> but I guess that's some library interpreting a configuration file or similar ...
[01:47] <stokachu> just to verify, https://wiki.ubuntu.com/Releases should quantal be EOL April 2013 and not 2014
[01:47] <slangasek> cjwatson: ah right, I overlooked that ~half the processes were actually sh -c.... but in my case, ps f doesn't show any parents for them, they've apparently been left behind :-P
[01:48] <slangasek> stokachu: it should not
[01:48] <slangasek> stokachu: 12.10 + 18mo -> Apr 2014
[01:48] <stokachu> oh then raring is off right?
[01:49] <stokachu> or will that change when its made stable
[04:55] <slangasek> stokachu: raring will AIUI be supported until Jan 2014
[04:55] <stokachu> slangasek: ah b/c of rolling release i assume?
[04:56] <slangasek> well, because of the discussion about shortening the support cycle
[04:56] <slangasek> we aren't actually having a rolling release :)
[04:56] <stokachu> :P sounds good to me
[04:57] <stokachu> i should probably catch up on my emails in the non fire group
[05:03] <tjaalton> slangasek: does the plymouth mp look good? :)
[05:05] <tjaalton> oh bah
[05:06] <tjaalton> wrong version number, took the ppa upload as-is
[05:08] <tjaalton> fixed
[10:21] <smartboyhw> kirkland, roaksoax ping. I'm having problems adding a flavour to Testdrive code.
[10:33] <smartboyhw> ^ please ignore, I think I found the problem.
[13:23] <doko> jtaylor, https://launchpad.net/ubuntu/+archive/test-rebuild-20130329/+build/4440877 numpy related?
[14:56] <purezen> Hey guys..!! I wanted to know if the updates enabling Hardware Video Acceleration via UVD on ATI Radeon HD 4000 through MESA have arrived on Ubuntu 12.10 x64 yet..?
[14:59] <jtaylor> doko: numpy related but probably not 1.7.0 -> 1.7.1 related, the headers have not changed
[15:01] <jtaylor> I'll have a look
[15:07] <jtaylor> doko: pytiff sets NPY_NO_DEPRECATED_API but does not set the api version
[15:16] <jtaylor> though there is probably an additional inconsistency in numpy I'll check with upstream
[15:24] <jtaylor> no numpy is fine, just pytiff doing wrong stuff
[15:25] <jtaylor> doko: http://paste.ubuntu.com/5724729/ should fix it
[15:25] <jtaylor> it uses 1.6 API so it can'T disable deprecated api
[15:25] <jtaylor> specifically PyArray_CORDER instead of NPY_CORDER
[15:29] <doko> jtaylor, can you upload?
[15:30] <jtaylor> yes
[15:47] <jtaylor> done
[16:35] <slangasek> bdmurray: is bug #1036081 something we've seen before?  Users are trying to install the 'sysvutils' binary package on 12.04, when that package was last available in lucid
[17:10] <nonickname2> could someone with casper or plymouth knowledge maybe look at bug #1170421 and/or is this bug something for the release notes? only tested on/with kubuntu though, so maybe someone could try to reproduce it on another *buntu (taking the testing results in the bug report into account)?
[17:23] <slangasek> bdmurray: ok, having looked closer I see that this is an issue we've discussed before; but I don't know if there was a master bug for it somewhere?
[17:41] <sreich> i've got uhm..a bit of a concern with clang 3.2
[17:41] <sreich> as in, there's a 100% of the time crash on anything that uses C++11's std::thread with 3.2, from what i can tell.
[17:41] <sreich> the bug is here http://llvm.org/bugs/show_bug.cgi?id=12730
[17:42] <sreich> they fixed it in r178816 (a couple weeks ago)
[17:42] <sreich> thing is i don't think llvm itself backports fixes..is it possible for ubuntu to squeeze that in?
[17:42] <sreich> because that's a pretty serious bug imho
[17:42] <sreich> or should i be contacting llvm to have them backport it (maybe i am wrong and they do push bugfix releases?)
[17:51] <jtaylor> sraue: depending on the invasivness of the fix we can fix it for raring
[17:51] <jtaylor> sreich: ^
[17:51] <jtaylor> though probably via an stable release update at this stage
[17:52] <jtaylor> sreich: forwarding it to debian would also help, llvm is maintained there
[17:52] <sreich> ok
[17:53] <jtaylor> clang 3.0 is not affected?
[17:53] <sreich> no idea
[17:53] <sreich> don't think 3.0 even had std::thread support
[17:53] <jtaylor> probably not I'll try
[17:53] <sreich> but to check you can just run the source file there
[17:55] <jtaylor> hm it doesn'T compile unless you remove a static assert and then it crashes :/
[17:56] <sreich> yeah it's a bit on the edge i guess http://clang.llvm.org/cxx_status.html
[17:56] <sreich> could be 3.1..or 3.2, don't really know
[18:00] <jtaylor> the fix looks quite simple
[18:00] <jtaylor> bit I'd like the debian maintainers opinion on it first
[18:05] <sreich> jtaylor: where can i get them?
[18:05] <sreich> is there a #debian-devel  ?
[18:05] <bdmurray> slangasek: bug 1001904
[18:05] <jtaylor> sreich: by filing a bug
[18:05] <sreich> k
[18:05] <jtaylor> sreich: debian experimental has pretty much the same clang version
[18:06] <jtaylor> sreich: you can use reportbug -B debian clang
[18:27] <sreich> wow, reporting a debian bug on a non-debian system is fun
[18:28] <sreich> they use emails to create bug reports. like..seriously?
[18:28] <sreich> what is this, 1980?
[18:30] <jtaylor> I think its great
[18:30] <jtaylor> the debian bug tracking system is the best I yet encountered
[18:30] <sreich> seriously?
[18:31] <sreich> why? to report a bug..you need to send an email?
[18:31] <jtaylor> everybody has email
[18:31] <sreich> everybody has bugzilla
[18:31] <jtaylor> you usually need to register for that
[18:31] <jtaylor> which requires email
[18:32] <jtaylor> bts just skips this step
[18:32] <sreich> yeah, but it's got a sane interface
[18:32] <sreich> email is error prone
[18:32] <sreich> and as mentioned, reportbug isn't on non-debian systems
[18:34] <jtaylor> reportbug is just for convinience
[18:34] <sreich> yeah, which you don't get on non-debian systems apparently ;)
[18:34] <jtaylor> I usually just write an email with, Package: ... VErsion: .. bugtext
[18:34] <sreich> hence my point about not using a bug management system seems silly
[18:34] <sreich> i could understand having both, but just one?
[18:35] <jtaylor> it is occasionally discussed to add a webinterface
[18:35] <jtaylor> its usually rejected because its to easy to use :)
[18:36] <sreich> heh
[18:36] <jtaylor> "if someone is not able to write an email, the bug report will not be useful anyway"
[18:39] <mlankhorst> but what if its a bug about thunderbird? ;)
[18:47] <dtchen> is there another archive rebuild test running? I just attempted to reload a build log from the 0329 test, and it had disappeared. :)
[18:47] <jtaylor> which package?
[18:47] <dtchen> mysql-workbench, amd64
[18:48] <sreich> jtaylor: not finding clang 3.2 in debian at all
[18:48] <sreich> http://packages.debian.org/unstable/devel/
[18:49] <jtaylor> dtchen: strange, the i386 log is still there though
[18:49] <dtchen> sreich: looks like it's in experimental
[18:49] <sreich> where can i view experimental?
[18:49] <dtchen> jtaylor: yeah, I ended up using that one as a starting point. Thanks.
[18:50] <jtaylor> sreich: the package trackign system has all information: http://packages.qa.debian.org/c/clang.html
[19:16] <xnox> Anyone have any pointers as to where is the code that generates https://patches.ubuntu.com ?
[20:40] <slangasek> bdmurray: right, thanks
[21:51] <cjwatson> xnox: lp:merge-o-matic
[21:55] <xnox> cjwatson: ok, didn't know it's the same =)
[22:05] <stgraber> fauxww
[22:05] <stgraber> chvt 7
[22:06] <stgraber> chvt 8
[22:06] <stgraber> 0~0~/valogXcd ..
[22:06] <stgraber> cd ..
[22:06] <stgraber> cd vanhoof Logan_
[22:06] <stgraber> ls
[22:06] <stgraber> cat xnox 0 | less
[22:07] <xnox> stgraber: ?????
[22:07] <stgraber> qconso
[22:07] <stgraber> ubuntu
[22:07] <stgraber> ubuntu
[22:07] <stgraber> sudo -i
[22:07] <stgraber> ubuntu
[22:07] <stgraber> ps fauxww
[22:07] <xnox> "Ctrl-Alt-t" | stgraber
[22:07] <stgraber> cat /var/log/upstart/li
[22:08] <stgraber> restart lightdm
[22:08] <xnox> I take it stgraber is trying to recover his machine blind =)
[22:09] <ogra_> lol, yeah, good guess
[22:09] <xnox> ogra_: let's just wait for the sudo password =)
[22:09] <ogra_> he obviously uses ubuntu/ubuntu :)
[22:09] <xnox> ogra_: ha, true.
[22:10] <Logan_> hahaha
[22:10] <Logan_> this is quite amusing
[22:10] <stgraber> oops ;)
[22:10] <Logan_> btw, you need a stronger password
[22:11] <xnox> stgraber: or is it focus-failing-to-follow-eyesight-error ?
[22:11] <stgraber> xnox: nope, I'm reinstalling my laptop, running a bare Ubuntu server on it and running Ubuntu desktop inside an LXC container
[22:11] <stgraber> I was at the setting up input devices step ;)
[22:11] <ogra_> it worked !
[22:11] <ogra_> :)
[22:12] <stgraber> which apparently ended up working a bit too well as the X server running in a non-focused VT was still getting the keyboard input (apparently)
[22:12] <stgraber> looks like a reboot fixed it though ;)
[22:13] <xnox> stgraber: i can get a mouse pointer working on a VT sometimes......
[22:13]  * xnox praises Intel graphics
[22:13] <xnox> like a tty1 that is.
[22:13] <stgraber> xnox: yeah, I had that and it's when that happens that you can get in the situation where what you type in tty1 ends up in both the tty and in your focused X window (in my case, irssi)
[22:15] <stgraber> anyway, sorry for the spam, it hopefully won't happen again (will try to keep something else focused when doing my tests ;))