[07:31] -queuebot:#ubuntu-release- New sync: fsspec (focal-proposed/primary) [0.6.1-0.1]
[07:34] <LocutusOfBorg> ^^ this one overrides python-fsspec, with the Debian updated package
[07:34] <LocutusOfBorg> doko, ^^
[08:05] <handsome_feng[m]> LocutusOfBorg, thanks!
[08:48] <rbalint> sil2100, i've a few related fixes for eoan, could you please accept them in your sru cycle?  pam, update-notifier, ubuntu-release-upgrader, base-files, update-motd, ubuntu-meta
[09:21] <RikMills> morning. seed changes in git/bzr are not propogating to https://people.canonical.com/~ubuntu-archive/seeds/
[09:24] <RikMills> for example, changes made over the weekend in ubuntu.focal/wsl and kubuntu.focal/
[09:24]  * RikMills is never sure quite who to ping on these things
[09:25] <apw> there are few who know how that is all plumbed in that is for sure
[09:27] <apw> RikMills, ok interesting it looks to have hung at the same time i had a hang in my tooling (which also talks to launchpad)
[09:31] <apw> RikMills, is that any better
[09:34] <RikMills> apw: not yet. not sure if the update is trigger on a seed git/bzr change, or just a cron type thing to be honest
[09:34] <apw> RikMills, the ubuntu.focal/wsl file seems to have changed today
[09:34] <apw> (now)
[09:35] <apw> wsl 2019-12-09 09:30 728
[09:35] <RikMills> yeah, just did right on my next refresh
[09:35] <RikMills> kubuntu is still lagging, bit will give it a little time
[09:36] <apw> RikMills, i'd say the sync is complete, so if it is not in sync now it isn't going to get more so
[09:37] <sil2100> rbalint: will see if I get to those
[09:38] <RikMills> apw: :(
[09:46] <RikMills> apw: I made another small change (added back a comment I was going to put back anyway), and it updated then :)
[09:46] <RikMills> thank you
[09:52] <apw> RikMills, no that updated because i updated it by hand
[09:53] <RikMills> oh :/
[09:57] <apw> RikMills, still debugging it
[10:03] <apw> not sure who added the cowboy to archive-reports, but it is catching something and reporting it in mail
[10:36] <apw> RikMills, ok with some debugging added it seems it was a lost bzr lock; yay for seeds still in bzr; should be updating more normally now.
[10:41] -queuebot:#ubuntu-release- New: accepted fsspec [sync] (focal-proposed) [0.6.1-0.1]
[10:41] -queuebot:#ubuntu-release- New: accepted python-pbcore [amd64] (focal-proposed) [1.7.1+git20191121.7947eb7+dfsg-2ubuntu1]
[10:41] -queuebot:#ubuntu-release- New: accepted pmemkv [amd64] (focal-proposed) [1.0.1-1]
[10:41] <RikMills> apw: thank you!
[10:43] -queuebot:#ubuntu-release- New binary: fsspec [amd64] (focal-proposed/universe) [0.6.1-0.1] (no packageset)
[11:14] -queuebot:#ubuntu-release- New binary: nexus [s390x] (focal-proposed/universe) [4.4.3-2] (no packageset)
[11:16] -queuebot:#ubuntu-release- New binary: jsonld-java [amd64] (focal-proposed/universe) [0.13.0-2] (no packageset)
[11:16] -queuebot:#ubuntu-release- New binary: nexus [ppc64el] (focal-proposed/universe) [4.4.3-2] (no packageset)
[11:16] -queuebot:#ubuntu-release- New binary: nexus [amd64] (focal-proposed/universe) [4.4.3-2] (no packageset)
[11:17] -queuebot:#ubuntu-release- New binary: nexus [arm64] (focal-proposed/universe) [4.4.3-2] (no packageset)
[11:17] -queuebot:#ubuntu-release- New binary: nexus [armhf] (focal-proposed/universe) [4.4.3-2] (no packageset)
[11:18] -queuebot:#ubuntu-release- New: accepted fsspec [amd64] (focal-proposed) [0.6.1-0.1]
[11:18] -queuebot:#ubuntu-release- New: accepted nexus [amd64] (focal-proposed) [4.4.3-2]
[11:18] -queuebot:#ubuntu-release- New: accepted nexus [armhf] (focal-proposed) [4.4.3-2]
[11:18] -queuebot:#ubuntu-release- New: accepted nexus [s390x] (focal-proposed) [4.4.3-2]
[11:18] -queuebot:#ubuntu-release- New: accepted jsonld-java [amd64] (focal-proposed) [0.13.0-2]
[11:18] -queuebot:#ubuntu-release- New: accepted nexus [ppc64el] (focal-proposed) [4.4.3-2]
[11:18] -queuebot:#ubuntu-release- New: accepted nexus [arm64] (focal-proposed) [4.4.3-2]
[11:18] -queuebot:#ubuntu-release- New binary: hinge [amd64] (focal-proposed/universe) [0.5.0-5] (no packageset)
[11:19] -queuebot:#ubuntu-release- New binary: hinge [ppc64el] (focal-proposed/universe) [0.5.0-5] (no packageset)
[11:21] -queuebot:#ubuntu-release- New binary: hinge [arm64] (focal-proposed/universe) [0.5.0-5] (no packageset)
[11:27] <tjaalton> xorg-server is blocked on libdmx1 not being available for i386, so should it be added to the whitelist?
[11:28] <tjaalton> or drop xdmx-tools from i386?
[11:30] -queuebot:#ubuntu-release- New binary: thrift [s390x] (focal-proposed/universe) [0.13.0-2] (no packageset)
[11:30] <doko> I would be in favor of adding it, instead of adding deltas for such things to the packages
[11:31] <tjaalton> right
[11:31] <doko> vorlon: I don't see why libhsail-rt-9-dev is uninstallable ...
[11:32] <sil2100> seb128: hey! Since I see oSoMoN is not online, I have a question regarding the thunderbird upload to eoan, maybe you know: the previous update went into -security, should this one be targetting -security as well?
[11:33] <sil2100> seb128: I mean, the bug number mentions some upgrade issues, so this seems like something that would be useful for people fetching/upgrading thunderbird from -security as well?
[11:33] <seb128> sil2100, hey, I don't know sorry. Olivier was not feeling well this morning but he might be back online later, other maybe try to chec with chrisccoulson he might know
[11:35] -queuebot:#ubuntu-release- New binary: thrift [amd64] (focal-proposed/universe) [0.13.0-2] (no packageset)
[11:35] <sil2100> seb128: ok, will do, thanks o/
[11:36] <seb128> yw!
[11:38] -queuebot:#ubuntu-release- New binary: thrift [ppc64el] (focal-proposed/universe) [0.13.0-2] (no packageset)
[11:46] -queuebot:#ubuntu-release- New binary: linux-signed-gke-4.15 [amd64] (bionic-proposed/main) [4.15.0-1050.53] (no packageset)
[11:47] -queuebot:#ubuntu-release- New: accepted linux-signed-gke-4.15 [amd64] (bionic-proposed) [4.15.0-1050.53]
[11:54] -queuebot:#ubuntu-release- Unapproved: thunar (bionic-proposed/universe) [1.6.15-0ubuntu1 => 1.6.15-0ubuntu<IP_ADDRESS>] (mythbuntu, xubuntu)
[12:16] -queuebot:#ubuntu-release- New binary: thrift [armhf] (focal-proposed/universe) [0.13.0-2] (no packageset)
[12:18] -queuebot:#ubuntu-release- New binary: thrift [arm64] (focal-proposed/universe) [0.13.0-2] (no packageset)
[12:31] -queuebot:#ubuntu-release- New: accepted hinge [amd64] (focal-proposed) [0.5.0-5]
[12:31] -queuebot:#ubuntu-release- New: accepted hinge [ppc64el] (focal-proposed) [0.5.0-5]
[12:31] -queuebot:#ubuntu-release- New: accepted thrift [arm64] (focal-proposed) [0.13.0-2]
[12:31] -queuebot:#ubuntu-release- New: accepted thrift [ppc64el] (focal-proposed) [0.13.0-2]
[12:31] -queuebot:#ubuntu-release- New: accepted hinge [arm64] (focal-proposed) [0.5.0-5]
[12:31] -queuebot:#ubuntu-release- New: accepted thrift [armhf] (focal-proposed) [0.13.0-2]
[12:31] -queuebot:#ubuntu-release- New: accepted thrift [amd64] (focal-proposed) [0.13.0-2]
[12:31] -queuebot:#ubuntu-release- New: accepted thrift [s390x] (focal-proposed) [0.13.0-2]
[12:36] -queuebot:#ubuntu-release- New source: pyfftw (focal-proposed/primary) [0.11.1-3ubuntu2]
[12:57] -queuebot:#ubuntu-release- New: accepted pyfftw [source] (focal-proposed) [0.11.1-3ubuntu2]
[13:05] -queuebot:#ubuntu-release- New binary: pyfftw [s390x] (focal-proposed/none) [0.11.1-3ubuntu2] (no packageset)
[13:11] -queuebot:#ubuntu-release- New binary: pyfftw [ppc64el] (focal-proposed/universe) [0.11.1-3ubuntu2] (no packageset)
[13:15] -queuebot:#ubuntu-release- New: accepted pyfftw [ppc64el] (focal-proposed) [0.11.1-3ubuntu2]
[13:15] -queuebot:#ubuntu-release- New: accepted pyfftw [s390x] (focal-proposed) [0.11.1-3ubuntu2]
[13:22] -queuebot:#ubuntu-release- New binary: pyfftw [amd64] (focal-proposed/universe) [0.11.1-3ubuntu2] (no packageset)
[15:20] <sil2100> rbalint: hey, so looking at update-motd - the bug is missing a test case and regression potential
[15:20] -queuebot:#ubuntu-release- New: accepted pyfftw [amd64] (focal-proposed) [0.11.1-3ubuntu2]
[15:38] <sil2100> rbalint: hm, the update-notifier SRU has a lot of unrelated changes regarding the Makefile's etc. being generated by an older automake (was by 1.16.1 and 1.15.1), this makes it quite hard to review
[15:40] <rbalint> sil2100, yes, this is a consequence of having the obsolete prebuild directive, should i rebuild the source to cut those changes off?
[15:41] <rbalint> sil2100, looking at update-motd
[15:47] <sil2100> rbalint: yeah, if you could, since this way the diff is unnecessarily bloated
[15:47] <rbalint> sil2100, i've finished the update-motd sru template
[15:51] -queuebot:#ubuntu-release- Unapproved: update-notifier (eoan-proposed/main) [3.192.26 => <IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[15:53] <sil2100> rbalint: hm, for u-r-u, the demotion list is very suspicious - I had that once already, but Steve and Adam told me that usually after release the demotion lists should not be modified
[15:53] <sil2100> rbalint: so last time I had an update like that, Steve reverted the changes with the next upload
[15:55] <sil2100> rbalint: I rejected it for now, we'd need this re-uploaded without the demoted.cfg changes etc.
[15:55] -queuebot:#ubuntu-release- Unapproved: rejected ubuntu-release-upgrader [source] (eoan-proposed) [1:<IP_ADDRESS>]
[15:55] <sil2100> rbalint: looking at update-motd again, thanks o/
[15:56] <sil2100> rbalint: (you can see almost the same demotions changes in my upload http://launchpadlibrarian.net/446106940/ubuntu-release-upgrader_1%3A19.10.13_1%3A19.10.14.diff.gz and as said, .15 reverted those back to the state it's in now)
[15:56] <rbalint> sil2100, re: demotion changes: makes sense
[15:56] <sil2100> I think the tooling is just a bit stupid there
[15:58] <vorlon> doko: ah, libhsail-rt-9-dev isn't uninstallable.  so it's something else
[15:59] <doko> it's gccbrig-N, so added hsail-tools to the whitelist
[15:59] -queuebot:#ubuntu-release- Unapproved: accepted update-motd [source] (eoan-proposed) [3.6-0ubuntu<IP_ADDRESS>]
[16:01] <doko> vorlon: and all the dbg packages are removed in focal
[16:02] <vorlon> doko: why are you adding hsail-tools to the whitelist?
[16:03] <doko> vorlon: why do you want to modify packages to fit the whitelist?
[16:03] -queuebot:#ubuntu-release- New binary: update-motd [amd64] (eoan-proposed/main) [3.6-0ubuntu<IP_ADDRESS>] (core)
[16:03] <vorlon> because we want to reduce what we have to support on i386.  Do you want to debug i386+hsail-specific problems?
[16:04] <doko> did you see any specifc i386+hsail-specific problems? no? then please keep it
[16:04] <doko> a related question came up with xorg-server, see above
[16:07] <vorlon> doko: infinity and I had talked about this here over the weekend; I don't think we should be adding things to the whitelist to satisfy binary deps of packages built from sources we need, I think we should prune the binaries
[16:08] <doko> introducing deltas for all these packages? I don't think it's worth it
[16:09] <vorlon> I'll work up an implementation that's upstreamable
[16:09] <vorlon> I agree we don't want deltas on all of them
[16:10] <doko> and I don't want to cripple the gcc-N package to c/c++ only
[16:11] <rbalint> i don't think this is worth spening time on but it is not up to me
[16:11] <doko> well, it will be time on you, if you have to merge those packages
[16:11] <vorlon> doko: the 32-bit host toolchain is *only* in the archive for purpose of building the packages in the whitelist
[16:12] <doko> you don't gain anything by this
[16:12] -queuebot:#ubuntu-release- Unapproved: rejected update-notifier [source] (eoan-proposed) [<IP_ADDRESS>]
[16:13] <rbalint> i mean the decision is not up to me
[16:13] <doko> well, we could bring it up to the tb
[16:27] <sil2100> rbalint: uh, is it normal that now all the automake bits are gone from update-notifier?
[16:32] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-meta [source] (eoan-proposed) [1.440.1]
[16:34] <rbalint> sil2100, :-\ let me keep them intact
[16:37] <sil2100> I mean, I guess hm, we could remove them if they're generated during build, but for SRUs it's best if unneeded changes are at a minimum
[16:51] -queuebot:#ubuntu-release- Unapproved: ubuntu-release-upgrader (eoan-proposed/main) [1:<IP_ADDRESS> => 1:<IP_ADDRESS>] (core)
[16:59] <rbalint> sil2100, ^
[16:59] <rbalint> sil2100, since I changed Makefile.am in update-notifier i need to regenerate Makefile.in, but i do it in eoan in the next upload
[17:11] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (eoan-proposed) [1:<IP_ADDRESS>]
[17:14] -queuebot:#ubuntu-release- Unapproved: update-notifier (eoan-proposed/main) [3.192.26 => <IP_ADDRESS>] (ubuntu-desktop, ubuntu-server)
[17:16] <rbalint> sil2100, thanks, the hopefully last one ^ :-)
[17:17] -queuebot:#ubuntu-release- New binary: python-nxs [amd64] (focal-proposed/none) [4.4.1-2] (no packageset)
[17:29] -queuebot:#ubuntu-release- Unapproved: rejected update-notifier [source] (eoan-proposed) [<IP_ADDRESS>]
[17:34] -queuebot:#ubuntu-release- Unapproved: accepted update-notifier [source] (eoan-proposed) [<IP_ADDRESS>]
[19:39] <slashd> vorlon or any release team member, could you please unblock my sosreport upload in focal for i386 adt: http://autopkgtest.ubuntu.com/packages/s/sosreport/focal/i386
[19:43] <vorlon> slashd: done
[19:48] <slashd> vorlon, thanks
[19:52] -queuebot:#ubuntu-release- Unapproved: designate-dashboard (bionic-proposed/universe) [6.0.0-0ubuntu1.1 => 6.0.0-0ubuntu1.2] (no packageset)
[20:01] -queuebot:#ubuntu-release- New: accepted python-nxs [amd64] (focal-proposed) [4.4.1-2]
[20:16] <xnox> vorlon:  pgl-ddl-deploy is triggered by autopkgtest on i386
[20:16] <xnox> i don't understand how or why, what do i do? it failed.
[20:17] <xnox> it doesn't exist on i386 at all
[20:17] <xnox> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#pgl-ddl-deploy
[20:20] <xnox> dunno https://code.launchpad.net/~xnox/britney/hints-pgl-ddl-deploy/+merge/376538
[20:20] <xnox> but imho that should not have been requested, should it have?
[20:25] <vorlon> xnox: it /shouldn't/ have, but there's some bug I have not dug into with britney where it requests tests on architectures for which the binaries have recently been deleted
[20:26] <vorlon> so we have to badtest it, and then remove the badtest :P
[20:26] <xnox> fun
[20:26] <xnox> vorlon: please make it so
[20:26] <xnox> because we didn't purge the britney cache?
[20:26] <xnox> it doesn't use like real things between the runs
[20:26] <vorlon> I have no idea, I have not dug into it
[20:27] <vorlon> I know the shape of the bug based on the symptoms
[20:29] <vorlon> xnox: I'm rejecting your mp because I have a section in the file for the i386-related hints where I'm keeping them all together
[20:47] -queuebot:#ubuntu-release- Unapproved: accepted livecd-rootfs [source] (trusty-proposed) [2.208.18]
[23:15] -queuebot:#ubuntu-release- New binary: php-mikey179-vfsstream [amd64] (focal-proposed/universe) [1.6.7-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: php-psr-event-dispatcher [amd64] (focal-proposed/universe) [1.0.0-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: php-parsedown [amd64] (focal-proposed/universe) [1.7.3-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: python-dlt [amd64] (focal-proposed/universe) [2.0-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: php-httpful [amd64] (focal-proposed/universe) [0.2.20-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: php-php-mongodb [amd64] (focal-proposed/universe) [1.4.3-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: php-lorenzo-pinky [amd64] (focal-proposed/universe) [1.0.5-1] (no packageset)
[23:16] -queuebot:#ubuntu-release- New binary: php-tijsverkoyen-css-to-inline-styles [amd64] (focal-proposed/universe) [2.2.2-1] (no packageset)
[23:20] -queuebot:#ubuntu-release- New binary: starpu [s390x] (focal-proposed/universe) [1.3.3+dfsg-2] (no packageset)
[23:21] -queuebot:#ubuntu-release- New binary: starpu [ppc64el] (focal-proposed/universe) [1.3.3+dfsg-2] (no packageset)
[23:22] -queuebot:#ubuntu-release- New binary: starpu-contrib [amd64] (focal-proposed/multiverse) [1.3.3+dfsg-1] (no packageset)
[23:23] -queuebot:#ubuntu-release- New binary: starpu [amd64] (focal-proposed/universe) [1.3.3+dfsg-2] (no packageset)
[23:24] -queuebot:#ubuntu-release- New binary: starpu-contrib [ppc64el] (focal-proposed/multiverse) [1.3.3+dfsg-1] (no packageset)
[23:29] -queuebot:#ubuntu-release- New binary: starpu [armhf] (focal-proposed/universe) [1.3.3+dfsg-2] (no packageset)
[23:43] -queuebot:#ubuntu-release- New binary: starpu [arm64] (focal-proposed/universe) [1.3.3+dfsg-2] (no packageset)


[12:45] <lericson> Guys, it would be helpful if upstart didn't ignore jobs with whitespace-only lines in them.
[12:53] <jhunt> lericson: ?
[12:54] <lericson> I don't have much further to add, this might be fixed in the latest version.
[12:55] <lericson> echo -e 'stop on runlevel [016]\n \nrespawn\nexec wait 100' >job.conf
[12:55] <lericson> should trigger it
[12:55] <lericson> apparently not
[12:56] <lericson> ok i don't really know what triggers it
[12:56] <lericson> this commit fixed it for me http://pb.lericson.se/p/BhCOQm/
[12:59] <jhunt> lericson: ? that change shouldn't make any difference.
[13:02] <lericson> wellp it did
[13:02] <lericson> also why can't I symlink job descriptions?
[13:02] <lericson> would be very convenient as we check our source out in /usr/local/share/
[13:03] <lericson> guess I could hardlink but that seems like the wrong kind of solution here
[13:31] <jhunt> lericson: http://upstart.ubuntu.com/cookbook/#symbolic-links-don-t-work-in-etc-init
[13:32] <jhunt> lericson: please could you raise a bug if the whitespace behaviour you are seeing is repeatable.
[13:33] <lericson> I am convinced, thank you
[13:34] <jhunt> the latest version of upstart does provide a --confdir=/usr/local/share but use at your own risk.
[13:35] <jhunt> also, you *could* make /etc/init/ a symbolic link to /usr/local/share, but again, you get to keep the pieces if your system breaks :)
[13:44] <lericson> not doing that, thank you very much :D
[13:44] <lericson> perhaps I should just make it part of my deploy step to copy new configuration files
[15:33] <SpamapS> lericson: that sounds like a plan


[12:47] <andrewlsd> Afternoon all
[15:58] <inetpro> good evening
[15:58] <Maaz> inetpro: By the way, Kilos on freenode told me "tell inetpro on freenode, i forgot to remember to tell me and you there is a meeting. ai!" 4 days, 8 hours, 1 minute and 15 seconds ago
[15:59] <inetpro> sjoe... I been quiet that long?
[16:34] <pavlushka> ahoy ZA!
[16:36] <pavlushka> he he inetpro, you are really? :p
[16:42] <inetpro> pavlushka: sorry
[16:43]  * inetpro just forgot to connect here
[16:43] <pavlushka> inetpro: dont be
[16:43] <pavlushka> inetpro: you didn't even missed me
[16:43] <pavlushka> but I already missed a guy in our channel
[16:43] <pavlushka> :(
[16:43] <pavlushka> So I am sorry :|
[16:43] <inetpro> hmm...
[16:44] <inetpro> Maaz: coffee please
[16:44] <Maaz> inetpro: There isn't a pot on
[16:45] <inetpro> Maaz: coffee on
[16:45]  * Maaz flips the salt-timer
[16:45] <inetpro> we'll just fix it all over a cup of joe
[16:46] <pavlushka> inetpro: something is flowing in a different direction in Ubuntu these days, got a little quiet including me :)
[16:46] <pavlushka> Maaz: coffee please
[16:46] <Maaz> pavlushka: Sure
[16:49] <Maaz> Coffee's ready for inetpro and pavlushka!
[16:49] <inetpro> Maaz: dankie
[16:49] <Maaz> Groot plesier inetpro my vriend
[19:27] <NeRoboto> I think someone needs to update the topic, guys.
[19:27] <NeRoboto> Also, hi.


[16:41] <CarlFK> I am having trouble with the net installer - the kernel finds the SD card reader (with no card in it) first, gives it sda, which breaks preseed d-i partman-auto/disk string /dev/sda
[16:42] <CarlFK> wily install uses 4.2.0-25-generic, finds the spiny disk first.
[16:43] <CarlFK> wily installer uses 4.2.0-16 , xenial installer uses 4.4.0-4, both find the card reader first
[16:44] <CarlFK> is there a param that will blacklist the card reader ?


[07:41]  * MetaCrab dòm dòm
[07:41] <PETsounds> Hello. Are there Ubuntu LoCo Hanoi i can contact? i'll be travelling to Hanoi and it would be nice to meet fellow Ubuntu users for coffee
[07:41] <MetaCrab> oh
[07:41] <stk> ya
[07:41] <MetaCrab> ummm
[07:42] <stk> but they are anti-social
[07:42] <stk> :V
[07:42] <MetaCrab> erm.. technically I am the contact for LoCo Hanoi, but our activity has fallen a lot lately
[07:42] <MetaCrab> by that I mean aside from me, there is no one else from Ubuntu-VN LoCo in Hanoi
[07:42] <stk> sure, thee Ambassador
[07:42] <MetaCrab> so... general FOSS community will do?
[07:43] <PETsounds> MetaCrab: i see
[07:43] <stk> by that he meant, there are way more cooler distros
[07:44] <PETsounds> any community is good as long as they are friendly
[07:44] <stk> and folks all adopted those insted
[07:44] <MetaCrab> -> HanoiLUG, I think you can drop them an email :)
[07:44] <stk> dude, organize a coffee
[07:44] <stk> call the dudes
[07:44]  * MetaCrab _(:з」∠)_ lazing around
[07:45] <stk> PETsounds: from your hostname, I assume that you are working for Wikipedia, correct?
[07:45] <MrTuxHdb> MetaCrab: nope
[07:45] <MrTuxHdb> you're forget khanhpt, chungbd, ducgiang
[07:45] <MrTuxHdb> and favadi
[07:45] <MetaCrab> 'active' <---
[07:45] <PETsounds> MetaCrab: ok PM me the email address, thanks
[07:45] <favadi> ?
[07:45] <favadi> wut?
[07:46] <MrTuxHdb> i think maybe khokho` too
[07:46] <PETsounds> stk: no i am a contributor
[07:47] <stk> PETsounds: there are plenty of FOSS engineers in Hanoi
[07:47]  * MetaCrab _(:з」∠)_
[07:47] <stk> just that they don't use Ubuntu (anymore) :V
[07:47] <stk> because it's lame, righto MetaCrab? :V
[07:47] <MetaCrab> well, I'm typing this on an Ubuntu-machine, using ncursed based irc client
[07:48] <MetaCrab> at least it hasn't broken down yet
[07:48] <stk> wow
[07:48] <stk> you have to bring it up
[07:48] <MrTuxHdb> stk: ubuntu everywhere!
[07:48] <stk> ncurse you
[07:49] <stk> PETsounds: welcome to Vietnam in advanced
[07:49] <stk> hope that you enjoy your trip
[07:50] <stk> advance*
[07:50] <PETsounds> stk: thank you, it will be my Second visit to Hanoi
[07:50] <stk> I don't live in HN so can't join, unfortunately
[07:50] <stk> but there are plenty FOSS engineers there
[08:05] <MetaCrab> aaaaaa
[08:05] <MetaCrab> an KDE user
[08:40] <stk> :V
[08:40] <MetaCrab> stk: one of your kind
[08:40] <stk> good


[00:19] <andras-kovacs> wow there is sg. strange with cloud-init on RHEL7.8 It didn't start as previously
[10:53] <andras-kovacs> I could trigger cloud-init-local, but cloud-init.service didn't run
[11:18]  * andras-kovacs sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/iAKNrOfaoBqRjPsUCkIAQSak >
[11:19] <andras-kovacs> I'm disabling cloud-init from my kickstart file, than enable it when I finish the VM build with packer from a cleanup script. So the first run should happen only when I make a new vm from the template. Now I'll give a try to disable cloud-init with a file or kernel parameter instead of messing with the systemd units from the kickstart. Because the service units are enabled but they don't start on the "second" boot
[11:19] <andras-kovacs> -> even there is no cloud-init logs, I ran cloud-init clean, etc.
[11:20] <andras-kovacs> Ofc if I find the source of the problem, I'll report it to RHEL
[11:26] <andras-kovacs> maybe cloud-init.target is not in the boot goals hmm.
[12:00] <andras-kovacs> That's the case! I can't see any cloud-init related service in the critical chain.
[12:00] <andras-kovacs> * systemd-analyze critical-chain I mean
[12:08] <andras-kovacs> "already disabled: no change needed [no /run/systemd/generator.early/multi-user.target.wants/cloud-init.target]"
[12:16] <andras-kovacs> cloud-config.service is now WantedBy=cloud-init.target
[12:16] <andras-kovacs> perviously it was WantedBy=multi-user.target
[12:22] <andras-kovacs> same story with cloud-init.service
[13:04] <andras-kovacs> So IMHO this is the same issue: https://bugs.launchpad.net/cloud-init/+bug/1771382
[13:04] <andras-kovacs> or really similaer
[13:09] <andras-kovacs> it don't need to modify / override the unit files, only: mv /etc/systemd/system/cloud-init.target.wants/* /etc/systemd/system/multi-user.target.wants/
[13:09] <andras-kovacs> And it works!
[13:09] <andras-kovacs> finally
[14:11] <andras-kovacs> The bug was filed already here: https://bugzilla.redhat.com/show_bug.cgi?id=1820540
[14:11] <andras-kovacs> I added my notes and findings.
[14:18] <andras-kovacs> Maybe... it's not so obvious now cloud-init has many modules what get executed all the time a server boots up.


[17:36] <leitao> quick question about launchpad build package page. What does PROPOSED/RELEASE means on the title? Example: https://launchpad.net/ubuntu/+source/powerpc-utils/1.2.18+r1.1.3-24ubuntu1/+build/5604267 and https://launchpad.net/ubuntu/+source/mozjs17/17.0.0-2/+build/6406057
[17:38] <cjwatson> leitao: that's the pocket: PROPOSED -> e.g. trusty-proposed, RELEASE -> e.g. trusty
[17:39] <cjwatson> leitao: most Ubuntu builds happen in proposed nowadays, but there are some exceptions.  In the case of the first build there, it was part of the initial ppc64el bootstrap, which was operating mostly on packages that had already auto-migrated from trusty-proposed to trusty.
[17:40] <leitao> cjwatson, got it. Makes sense. Thank you
[17:40] <cjwatson> np


[12:37] <dilys> Merge to<EMAIL_ADDRESS>changed bug assignment statuses to the more clearly-named New, Accepted, Rejected and Fixed to overcome usability problems experienced while testing (patch-814)
[12:56] <BradB> Ouch, that
 change on bug messages is horrific
[01:25] <BradB> stub: dude, did you look at the
 change? :)
[01:26] <stub> I merged that into Rocketfuel, didn't I?
[01:27] <BradB> yeah, but i mean did you look at it in the UI? it's nasty dude.
[01:27] <BradB> because, of course, lines aren't wrapping anymore.
[01:27] <stub> Did some limited tests here. Hmm...
[01:29] <BradB> that's why i suggested only for code snippets.
[01:30] <stub> Still got the same problem. I need more CSS-fu I think :-(
[01:30] <BradB> stub: with code-only though, you only get the problem when people are stupid, which will happen from time to time, but i don't expect it to be the common case
[01:31] <BradB> e.g. i don't think pasting 100-column wide code snippets is the common case
[01:31] <stub> I feel certain that the common case will be forgetting to put in (or not even knowing) the special markup required to flag a code snippet.
[01:32] <BradB> in any case, i'm about the land a change to the default search criteria, so that it's New/Accepted. i'm leaving the other widgets alone until i've discussed them more with Mark, because he has some concern about them being difficult to handle when all the packages, products and people come into it.
[01:32] <BradB> stub: eh, you can only help the user so much, of course...
[01:33] <BradB> if you say "use
 for code snippets" and they don't, well...
[01:33] <BradB> it could even be a little note nearby the textarea
[01:33] <stub> If Malone does not do the right thing, people will use other systems. If we start accepting certain HTML codes, and making people escape them somehow when they want to include them, it will be yet-another-markup language and piss people off.
[01:34] <stub> And we can't fix this with documentation on the web, because of the email interface.
[01:34] <BradB> stub: it's not YAML though! it's just only allowing them to use HTML tags that we /can/ allow them to use whilst not creating a security compromise.
[01:35] <BradB> stub: email users will already be familiar with the web UI, and those that aren't should expect (and will have to) read a little tutorial on how to format their email correctly anyway.
[01:35] <stub> It is - people will be composing HTML in their text email clients, and god help the poor sods who are sending HTML mail.
[01:36] <BradB> and again, we're thinking too far ahead right now. we need some little bit of markup for code no matter which way you look at it, but we don't much care about the incoming mail UI atm, because (i hope) it won't be part of the first release anyway.
[01:36] <stub> Oh - I think I see. For the nice_pre, space should only be converted to   at the start of the line.
[01:38] <BradB> what problem does that solve?
[01:38] <stub> I'm thinking ahead to the email interface, because I don't want all our comments to break when we switch it on (because they were assuming fixed width display, and suddenly the system chooses to render them proportional with collapsed whitespace). (Hmm... I guess at least in this case we can run through and add the 'code' marker around the entire existing messages)
[01:38] <stub> It will allow the browser to break lines I think.
[01:39] <BradB> stub: dude, i think you're assuming everybody that uses malone uses mutt.
[01:39] <BradB> stub: rest assured, this isn't the case. think of all the gnome developers, kde developers, etc.
[01:39] <stub> At the moment, it is not breaking them because I stupidly told it to *not* break them in about the most explicit way possible.
[01:41] <stub> I don't mean text clients (oh... so 90's!).  I mean text mode. All developers I know only send plain text emails (if for no other reason than the flamage they receive on public forums)
[01:42] <BradB> stub: i'd be delighted if, when writing an email, all i had to do to highlight some code was:

[01:42] <BradB> x = 1

[01:42] <BradB> the font we had seemed pretty decent, as proportional fonts go
[01:43] <BradB> mixing prop with pre-for-code would look fairly professional, like, heck, our wiki.
[01:43] <stub> Yes, And I'd be pissed off at the system if i sent 'You need to do something like '
...
' and the system decided to interpret y markup, or worse still, only *some* of my markup.
[01:44] <BradB> stub: "interpret your markup"??! huh? we wouldn't touch anything inside the
, obviously
[01:45] <BradB> it's verbatim, which you'd expect.
[01:45] <BradB> and you'd understand why we do the same thing that other sites do in restricting html tags used for security reasons.
[01:46] <BradB> but anyway, gah, whatever, i'm not too arsed. i just hope we can do another rollout today, so that the statuses become more sane and the default search params become slightly more sane too.
[01:47] <BradB> stub: if sabdfl actually *likes* the look of all
 messages though, i'd boggle. :)
[01:48] <stub> Roundup looks like it is formatting the text server side to 80 columns (and preserving whitespace and using a monospace font)
[01:48] <stub> Actually, it looks quite fine here. You need to use a different monospace font that courier ;)
[02:15] <BradB> stub: will you be able to push up a new dogfood today?
[02:15] <stub> Yes
[02:15] <BradB> great...my patch for default search params should land any minute.
[02:16] <BradB> if i implement "Quick Searches" like at http://plone.org/collector, we can basically drop the bugs assigned to, and bug submitted by reports.
[02:16] <BradB> implement tomorrow, that is
[02:29] <stub> Sounds good.
[02:30] <stub> Get a good collection of default ones in and we won't have to bother with making used-defined quick searches either ;)
[03:15] <stub> lifeless: Does arch do anything sucky with line endings like subversion, or does it just leave them the way they were saved?
[03:53] <stub> kiko: So - Malone has this 'select a sourcepackage' requirement
[03:53] <stub> kiko: Unfortunately, there appears to be no way a user can select the correct sourcepackage without knowing the primary key id
[03:56] <stub> kiko: I suspect I either need to make UNIQUE(Sourcepackage.distro, Sourcepackage.sourcepackagename) or somehow only display a 'sane' list of sourcepackages (perhaps only displaying the sourcepackage with a given distro and name that has the latest creation date (which needs to be added))
[03:57] <kiko> hmmm
[03:57] <kiko> right.
[03:58] <kiko> There could be a problem with UNIQUE distro/name because of inherited packages, I think.
[03:58] <kiko> this part of the workflow really hasn't been considered yet, so it sucks to be you the first one to have the problem.
[03:59] <kiko> you *could* make a select distinct on them -- how do you feel about that?
[04:01] <stub> I can have multiple identical rows in the sourcepackage table, only differing by id. If I only display distinct rows, I need to know which one is 'current' and assign bugs to that, or perhaps I should always use the first one? I'm really not sure
[04:02] <kiko> can't people file bugs against old releases?
[04:02] <stub> I personally think that we either need UNIQUE(Sourcepackage.distro, Sourcepackage.sourcepackagename) or refactor the database schema - the situation seems wrong.
[04:02] <stub> kiko: If they can, they have no way of telling the old releases from the new ones at the moment.
[04:02] <stub> It isn't a database issue, it is a UI issue.
[04:03] <stub> (but I suspect the UI issue is caused by the database design, and that this design is causing problems elsewhere too)
[04:04] <stub> Do you know who would know if UNIQUE(distro, sourcepackagename) would break the model? People I've asked all suspect, but nobody can actually tell me a use case.
[04:05] <kiko> well
[04:05] <kiko> hmmmmmmm
[04:06] <stub> (we might have to move sourcepackage.maintainer into sourcepackagerelease to snapshot this historical information, but apart from that...)
[04:06] <kiko> sourcepackagename is merely a normalization table, avoiding duplicating the package name in the sourcepackage table.
[04:07] <stub> Yer - pointless optimization IMO but I havn't pushed it too hard ;)
[04:07] <kiko> the issue is that you can have multiple sourcepackages with the same name but representing different packages
[04:08] <kiko> so you could have a web browser called firebird and a database called firebird
[04:08] <kiko> however I do think that you can't have firebird the browser and firebird the database in the same distribution as it would, well, not work, right?
[04:09] <stub> That is what I think. If anything, the issue would be that if Ubuntu had firebird-the-browser in warty, and firebird-the-database in hoary.
[04:09] <stub> That might be our pathalogical use case?
[04:10] <stub> (If so, it indicates to me that sourcepackage should be related to distrorelease rather than distro)
[04:10] <stub> I'm not sure if the Manifest causes trouble - it isn't documented so I'm not sure about it.
[04:12] <stub> The other Malone alternative might be to assign bugs to a (distro, sourcepackagename) or a (distrorelease,sourcepackagename) instead of to a sourcepackage.
[04:13] <stub> Hmm... if that *is* our pathalogical use case, we might need to prevent it from happening anyway because an Ubuntu user upgrading that package might get a nasty surprise ;)
[04:47] <kiko> exactly
[04:48] <kiko> I think over a whole distro you need the sourcepackagename to be unique.
[04:48] <kiko> you'll need mark to confirm, though, because none of this is complicated unless we consider derivative distros, and that's where my knowledge endgs
[04:48] <kiko> ends
[04:49] <kiko> I really don't like sourcepackagename very much and I've said it often -- I don't think it brings us anything at all
[04:50] <stub> I need to dig up a database design book which explains why sourcepackagename is wrong - I've gotten too used to relying on my intuition and not having to rationalize my decisions to anyone else ;)
[04:53] <stub> Mark seemed to think the existing design on sourcepackage was required for some reason but was unable to come up with a use case - suggested it was discussed at the conference but I was hoping to have the UI fixed before then ;)
[04:55] <kiko> yeah.
[04:55] <kiko> so the use case you have is the user is trying to say in what package he's encountering the bug?
[08:01] <stub> lifeless: pqm hung
[08:01] <stub> elmo: pqm hung
[09:12] <stub> lifeless: pqm is hung
[09:13] <elmo> fixed
[09:37] <dilys> Merge to<EMAIL_ADDRESS>made New and Accepted the default statuses in the bug listing search (patch-815)
[09:47] <sabdfl> hey stub
[09:48] <sabdfl> stub: sourcepackagename is partly because a lot of the actual pointers in the real world are to sourcepackagename, not to a specific sourcepackage
[09:48] <sabdfl> the debian bug system, for example, assigns bugs to a sourcepackage name
[09:49] <sabdfl> even if we move sourcepackagename back into sourcepackage, you still have the basic problem that a sourcepackage with a given name is not unique
[09:50] <sabdfl> stub: can i merge the corrected BugMessage refactoring?
[09:50] <sabdfl> I added:
[09:50] <sabdfl> ALTER TABLE Message
[09:50] <sabdfl>     ALTER COLUMN id SET DEFAULT nextval('message_id_seq');
[09:51] <stub> yes - go for it.
[09:52] <stub> Keeping sourcepackagename in a seperate table makes sense when you factor in those references I guess (the arguments for become stronger and against less clear anyway).
[09:52] <sabdfl> it's a shitty situation, but we're trying to model a difficult problem
[09:53] <sabdfl> i'm thinking of refactoring Malone to assign bugs to (distro, sourcepackagename) rather than sourcepackage
[09:54] <stub> Yup - that would be a solution. I've just been poking people trying to workout the best solution, and if there is an underlying problem with the data model.
[09:56] <stub> I think we need to come up with the most pathalogical case we plan on supporting - the firebird one above seems pretty good, but I don't know if we want to support that behaviour or prevent it.
[09:59] <dilys> Merge to<EMAIL_ADDRESS>nice_pre CSS implementation for dogfooding (patch-816)
[10:24] <Kinnison> Dudes.
[10:35] <sabdfl> morning Kinnison
[10:36] <Kinnison> hey sabdfl
[10:37] <Kinnison> sabdfl: Assuming kiko and cprov agree; I'd like to have cprov working with me from Monday. Does that sound okay to you?
[10:38] <sabdfl> absolutely
[10:38] <sabdfl> stretch cprov a little
[10:38] <sabdfl> stub: ok, i'm using patch 4-10-0
[10:41] <sabdfl> easy on the quartering
[10:43] <Kinnison> Can I at least draw him?
[10:44] <sabdfl> steady on
[10:44] <sabdfl> he might take that personally
[10:44] <Kinnison> True; I'd best stick to keeping this purely professional
[10:47] <stub> Now PQM is awake again, I'll do a dogfood update. Yell now if people have patches they want rolled out today that aren't yet committed.
[10:54] <Kinnison> morning elmo
[10:54] <Kinnison> sabdfl: I did a very rough time-plan last night; I'm going through it now making sure it seems sane
[11:15] <dilys> Merge to<EMAIL_ADDRESS>bugmessage refactoring (patch-817)
[11:20] <Kinnison> sabdfl: Unfortunately every time I think I'm done; I think of another thing to get gina to do :-)
[11:23] <sabdfl> stub: did that bugmessage refactoring make it into the dogfood update?
[11:23] <stub> It will - just shutdown the existing services when I saw the dillys message
[11:24] <sabdfl> thanks!
[11:55] <Kinnison> cprov: is Kiko around?
[11:58] <sabdfl> SteveA: congrats on getting the ZODBAnnotations service up and running
[12:01] <SteveA> thx
[12:03] <SteveA> with the ftp server, I think we might want to put a try:except: around the callbacks
[12:03] <SteveA> and log errors at that point
[12:03] <Kinnison> SteveA: sounds like a sensible precaution
[12:07] <SteveA> stub: I just read the email about a simpler way to restore backups.  Is the "wisdom of the dba" being recorded anywhere other than the mailing list?
[12:09] <stub> Not at present. Something like an FAQ may be appropriate.
[12:10] <stub> Procedures that exist are documented in launchpad/database/schema/README, but that is more for acting-dba's.
[12:10] <cprov> Kinnison: no, I think
[12:13] <dilys> Merge to<EMAIL_ADDRESS>bugassignment renumbering (patch-818)
[12:13] <Kinnison> cprov: Any idea when he normally turns up?
[12:15] <cprov> Kinnison: sorry, but today I have no idea, maybe within this hour . may I help you ?
[12:16] <Kinnison> cprov: I need to talk with you and him ;-)
[12:17] <Kinnison> cprov: sabdfl has agreed to let me ask for your time on lucille :-)
[12:17] <Kinnison> cprov: Which will give you a chance to see how things work from the other end of the package process in soyuz ;-)
[12:29] <sabdfl> cprov: would you like to take on some of the deeper challenges in the package management system behind soyuz?
[12:30] <cprov> sabdfl: yes
[12:30] <Kinnison> Hurrah
[12:31] <sabdfl> cprov: excelle nt
[12:31] <cprov> sabdfl: I'm just getting a kind of lost helping SteveA and Brad to have "better output on failed tests" <wink>
[12:31] <sabdfl> you've done a great job on the front end so far
[12:32] <sabdfl> remember all those questions about "how uploads happen" and "what happens when a new package arrives" that I said not to worry about?
[12:32] <sabdfl> now's the time to start thinking about them :-)
[12:32] <sabdfl> Kinnison has made a good start and will lead  this work
[12:32] <sabdfl> you will work for Kinnison on tasks he assigns
[12:33] <sabdfl> he knows exctly what he wants done, and can help you when you get stuck
[12:33] <cprov> sabdfl: thanks, but I feel I can do more on it ... just need more "time" (48 hours day would be nice)
[12:33] <sabdfl> together you two need to get the back-end stuff working for the end of es-conf
[12:33] <cprov> sabdfl: great !
[12:35] <Kinnison> cprov: My plan involves getting you into the lucille stuff starting on Monday.  Does that sound enough or do you want more time than that? (sabdfl: Do you want cprov to be exclusively on lucille or partially on lucille until es-conf?)
[12:36] <sabdfl> Kinnison: i think lucille should remain your baby
[12:36] <sabdfl> give cprove related tasks with a lower learning curve
[12:36] <sabdfl> to start with
[12:36] <Kinnison> sabdfl: Yeah; my plan had that kind of ramp-up
[12:37] <sabdfl> so, for example, the build system integration
[12:37] <Kinnison> sabdfl: I have a identified quite a bit to do on gina for now ;-)
[12:37] <sabdfl> ok
[12:37] <cprov> Kinnison: 2 days to finish my current tasks will be enough
[12:37] <Kinnison> sabdfl: I think the build-system integration is actually quite a deep thing. I have a curve mostly planned out for now ;-)
[12:39] <sabdfl> ok
[12:48] <cprov> Kinnison: sabdfl: I'm very happy to work on this, let's book a meeting soon to talk about your plans and the targets
[12:48] <Kinnison> cprov: Yes; I'd like to make sure kiko is happy with all this too
[12:52] <cprov> Kinnison: let me help you with a simple phone call :)
[12:53] <cprov> Kinnison: done, in few minutes he will arrive
[12:53] <Kinnison> hi kiko
[12:53] <kiko> minutes!
[12:53] <kiko> hey everybody
[12:53] <kiko> today is "I hate SSL certificates" day!
[12:54] <Kinnison> kiko: To bring you up to speed... sabdfl and I had a meeting yesterday and we decided that it would be good to get cprov on board with me as a lucille developer. cprov is interested in this and we've basically agreed that he will start working with me on Monday. Is this okay with you?
[12:54] <cprov> kiko: sorry I should say "seconds" ...
[12:54] <kiko> Kinnison, sounds good to me -- cprov has been wanting to get his hands dirty on it for a while already I suspect.
[12:55] <kiko> I was actually curious because yesterday you said an extra pair of hands would be good
[12:55] <Kinnison> kiko: Excellent ;-)
[12:55] <kiko> I was going to offer but since the topic died out I thought you had reconsidered.
[01:04] <sabdfl> kiko: ssl certificates are paying for this little gig :-)
[01:05] <kiko> Kinnison, tell me more about where lucille is going
[01:05] <kiko> sabdfl, jesus, good point, you could give me some hints, openssl is kicking my ass.
[01:05] <sabdfl> hold on, this is really soyuz, not lucille
[01:05] <sabdfl> lucille is one component of soyuz
[01:05] <stub> Mmm.... SSL certificates. Although I did get a $25 amazon gift certificate in thanks for calling Thawte extortionists in a survey. Sorry Mark :-)
[01:05] <sabdfl> lucille manages APT archives for distros - ubuntu and derivatives
[01:06] <Kinnison> sabdfl: Lucille manages a tad more than that to be fair
[01:06] <sabdfl> stub: dude, i think they started that after i left
[01:06] <sabdfl> vrsn
[01:06] <Kinnison> sabdfl: She also manages the queues. She's the *archive manager*
[01:06] <kiko> excuses, excuses
[01:06] <sabdfl> what we are talking about is extending cprov's work to include more of the workflow of package management
[01:06] <Kinnison> sabdfl: Indeed; so queue stuff; upload handling etc.
[01:06] <kiko> including the web-presented side of it, I expect?
[01:07] <Kinnison> kiko: Yes; I hope so
[01:07] <sabdfl> from upload, through build, through publishing, and including offering the package to derivatives
[01:07] <sabdfl> kiko: especially :-)
[01:07] <sabdfl> Kinnison has a really good understanding of how that workflow should look
[01:08] <sabdfl> we need to give him a second pair of hands, and also someone with web / zope flair, so cprov sprung to mind
[01:08] <kiko> if this means we can finally fix the "Pending" feature in source package, I want to donate to the effort
[01:08] <sabdfl> kiko: yes it does
[01:09] <kiko> sabdfl, today's our first day running ubuntu diskless at async
[01:09] <sabdfl> kiko: ltsp?
[01:09] <kiko> we encountered a few tricky issues but all in all it's excellent.
[01:10] <kiko> no, ltsp runs apps on the server -- we run apps on the client. it's pure NFS.
[01:10] <sabdfl> can we sanely fold that into hoary as a standard feature?
[01:10] <kiko> I'd need to ask salgado, but there are a few package tweaks that would need to be done.
[01:11] <kiko> the issue is that what we do is install ubuntu into a directory on the server and export that via NFS
[01:11] <kiko> we use a custom-built kernel, and some init.d hacks
[01:11] <kiko> I wonder if this would be a "package" to install on the server or something else.
[01:11] <kiko> it's currently a tarball.
[01:12] <Kinnison> Sounds like ideally it'd be a debootstrap following by a chroot and an install of a few choice patching packages
[01:12] <kiko> (it would be an 800MB package)
[01:12] <kiko> Kinnison, let's talk a bit about this in spain, I'd like to package it nicely
[01:12] <Kinnison> s.following.followed.
[01:12] <Kinnison> kiko: make sure you note down to talk about it or I'll forget
[01:12] <kiko> sure thing
[01:24] <SteveA> carlos: we have a meeting in 5 minutes
[01:31] <stub> sabdfl: Should everyone with a chinstrap account be allowed to access a launchpad_dogfood backup?
[01:35] <elmo> stub: no
[01:37] <stub> elmo: Is there a group I can use? There is a request on launchpad@ to get a copy of the dumps for development work and I either need a drop point for people without accounts on mawson or deny it.
[01:37] <carlos> SteveA: I'm here
[01:37] <elmo> stub: who needs it who doesn't have an account on mawson?
[01:37] <carlos> elmo: I
[01:38] <elmo> anyone else?
[01:38] <stub> carlos requested it. I have no idea if there are others.
[01:38] <elmo> carlos: congratulations you now have an account
[01:39] <elmo> thanks for playing "Lucky Account Lotto"
[01:39] <carlos> X-)
[01:39] <stub> Ta elmo.
[01:39] <carlos> elmo: thanks
[01:49] <SteveA> daf: ???
[01:57] <SteveA> carlos: I have another meeting later, and other things to do today.  Let's talk anyway.  Daf can read later.
[01:57] <carlos> ok
[01:57] <carlos> here or #canonical-meeting?
[02:00] <stub> Do bzipped files rsync well?
[02:01] <SteveA> ok.  Is the rosetta alpha running on the dogfood system?
[02:02] <kiko> stub, well, not efficiently, but it works
[02:03] <carlos> SteveA: seems like some data is still pending of upload, but I'm not sure
[02:03] <carlos> SteveA: I know daf was uploading files already
[02:04] <SteveA> when we talked about it yesterday, we all thought that it could be done by the end of yesterday.
[02:04] <SteveA> what happened?
[02:06] <carlos> SteveA: I'm not sure, but I think the scripts we have to import the files were not updated with latest changes we hace when moving to the common infrastructure
[02:06] <SteveA> what, exactly, is left to do?
[02:07] <carlos> SteveA: guessing here (I was not able to talk with daf, I left to sleep before he finished). Import the files into launchpad
[02:07] <carlos> I think I got an account in mawson today, so I could help now daf
[02:07] <carlos> on this task
[02:08] <SteveA> ok.  I wish daf were here.
[02:08] <SteveA> daf: buy yourself a big alarm clock that has no "snooze" button.
[02:08] <carlos> :-P
[02:09] <SteveA> let's assume that the dogfood stuff will be done a bit later today.
[02:09] <carlos> ok
[02:09] <SteveA> next, we have two important things
[02:09] <SteveA> 1. get more people using rosetta
[02:10] <SteveA> 2. the rosetta team needs to lead the rest of launchpad in internationalizing the application
[02:10] <SteveA> before I went on vacation, I emailed a list of resources on how to internationalize applications in python and zope
[02:10] <SteveA> did you read these?
[02:11] <carlos> not in depth
[02:11] <carlos> but I got the idea
[02:11] <SteveA> did you start to apply what you had learned to the rosetta code?
[02:12] <carlos> not yet
[02:12] <carlos> I was working fixing bugs more than adding new feature
[02:12] <carlos> s
[02:12] <carlos> yesterday I started adding new features
[02:12] <SteveA> this is an important feature for dogfooding rosetta
[02:12] <carlos> so I will do it now
[02:12] <carlos> I mean, from now
[02:13] <SteveA> ok, great.  there are three parts to this.
[02:13] <SteveA> 1. start internationalizing rosetta
[02:13] <SteveA> 2. get the pot files into the rosetta dogfood system for translation
[02:14] <SteveA> 3. write up how to do this so that others on the launchpad team can see what they need to do to existing code, and what they need to do with new code.
[02:14] <SteveA> the rosetta team are the "internationalization csars" for launchpad.
[02:14] <carlos> :-)
[02:15] <carlos> SteveA: should we add projects to translate as we decide? (outside the list we already were talking about)
[02:16] <SteveA> you mean in addition to stuff from ubuntu, zope3, plone, zwiki ?
[02:16] <carlos> hmm, with all ubuntu resources we have already a big tasks
[02:17] <carlos> I was talking about which ubuntu resources should we add
[02:17] <carlos> until we could automatice the import
[02:18] <carlos>  /s/automatice/automate/
[02:18] <SteveA> okay
[02:19] <SteveA> the thing to consider is whether you can get more people using rosetta by adding a particular project
[02:20] <carlos> ok
[02:20] <carlos> and how are we going to translate ubuntu's website?
[02:21] <carlos> not sure if it will be handled by rosetta
[02:21] <SteveA> that doesn't have anything to do with rosetta at this point
[02:22] <carlos> ok
[02:26] <carlos> SteveA: anything else?
[02:27] <SteveA> that's it for now, at least until daf turns up and we can talk about the dogfood
[02:27] <carlos> ok
[02:27] <SteveA> keep me informed about how the internationalization stuff is going
[02:27] <SteveA> I can help out if you have questions
[02:28] <carlos> ok
[02:28] <carlos> will do
[02:29] <SteveA> thanks
[02:41] <carlos> SteveA: sorry, but I'm not able to find the links you sent about zope i18n, I read them but seems like I forgot to add a bookmark
[02:41] <carlos> do you have them around?
[02:44] <carlos> I think I found it: http://zope.org/Wikis/DevSite/Projects/ComponentArchitecture/HowToDoI18nAndL10nForZope3/Zope3Internationalization
[02:51] <dilys> Merge to<EMAIL_ADDRESS>No more unused imports in soyuz app components. BugAssignmentStatus ajustment. (patch-819)
[03:01] <SteveA> carlos: I have sent you another copy
[03:01] <carlos> SteveA: thanks
[03:04] <BradB> morning
[03:07] <Kinnison> Hey brad
[03:11] <carlos> SteveA: ok, I know why I didn't found it, it's inside my inbox folder instead of the folder I have with your mails ..
[03:13] <cprov> BradB: please, tell me the RIGHT way to set a customized "optionflags" for a set of python tests
[03:37] <BradB> cprov: canonical.functional.FunctionalDocFileSuite has an example of how to do it.
[04:04] <carlos> BradB: how is your css knowledge?
[04:05] <BradB> carlos: limited
[04:05] <carlos> hmm
[04:05] <BradB> why?
[04:05] <carlos> who knows css in launchpad team?
[04:05] <carlos> BradB: we have a problem with css in rosetta
[04:06] <carlos> Kinnison: could you look at http://localhost:8086/rosetta/projects/gnome/evolution/evolution-2.0/translate ?
[04:06] <carlos> Kinnison: from your local launchpad installation?
[04:06] <Kinnison> is that part of the default data?
[04:06] <carlos> we are showing check buttons and they are expanded because some css magic...
[04:07] <carlos> Kinnison: yes
[04:07] <carlos> you need default data
[04:07] <Kinnison> how do I load default data?
[04:07] <carlos> a make inside database/schema should be enough
[04:08] <carlos> launchpad/database/schema
[04:08] <Kinnison> okay
[04:09] <Kinnison> user/password?
[04:09] <carlos><EMAIL_ADDRESS>[04:09] <carlos> test
[04:09] <carlos> or<EMAIL_ADDRESS>and same password
[04:09] <Kinnison> okay; I can see the page
[04:09] <carlos> look under the language name
[04:10] <carlos> that's a check button
[04:10] <Kinnison> woah
[04:10] <carlos> that has the same size of the entry text
[04:10] <Kinnison> and you want to know why yes?
[04:10] <carlos> well, know why and fix it :-)
[04:14] <carlos> Kinnison: my X server died
[04:15] <Kinnison> The problem appears to be that the checkbox is inside a  tag
[04:16] <carlos> let me check it...
[04:16] <sabdfl> erk
[04:16] <sabdfl> i need some charset help / fu
[04:17] <sabdfl> any experts out there? stevea?
[04:19] <carlos> Kinnison: same problem moving the checkbox out of the label
[04:20] <carlos> Kinnison: the template is potemplate-translate.pt
[04:20] <Kinnison> where is that?
[04:20] <carlos> lib/canonical/launchpad/templates
[04:21] <carlos> Kinnison: http://gollum.pemas.net:8085/rosetta/projects/gnome/evolution/evolution-2.0/translate <- My local launchpad server
[04:23] <sabdfl> how do i make sure a string is unicode before sending it to the db?
[04:24] <sabdfl> i'm trying to put a bunch of emails into the db, and i hit one with 8-bit characters... BOOM
[04:24] <kiko> sabdfl, heh, same problem as in gina.
[04:24] <kiko> you can use my horrible-hack from it
[04:24] <sabdfl> ok, where's the code?
[04:25] <kiko> l/c/lp/scripts/gina/database.py:ensure_string_format()
[04:25] <Kinnison> carlos: Okay, I can fix it with an explicit style rule
[04:25] <Kinnison> carlos: add to your css the following:
[04:25] <SteveA> sabdfl: when you say "putting a bunch of emails in the database", is this a script?
[04:26] <carlos> Kinnison: ok
[04:26] <Kinnison> fieldset.message-strings input[type=checkbox]  { width: auto !important; }
[04:26] <Kinnison> carlos: try that
[04:30] <carlos> hmm
[04:30] <Kinnison> did that do it?
[04:30] <carlos> Kinnison: I added it to the end of launchpad.css
[04:30] <carlos> and I don't see any change
[04:30] <Kinnison> shift+ctrl+alt+hyper+meta+uber+reload?
[04:30] <Kinnison> In case mozilla has it cached
[04:31] <carlos> ok, that's the problem
[04:31] <carlos> it worked now
[04:31] <carlos> thanks
[04:31] <Kinnison> You're welcome
[04:31] <sabdfl> SteveA: yes it is a script
[04:31] <carlos> Kinnison: ;-)
[04:32] <sabdfl> i'm rewriting the debbugs-bugzilla syncer that mdz wrote, for malone-debbugs sync
[04:32] <sabdfl> Kinnison: wow, that's quite a memory
[04:33] <Kinnison> sabdfl: I needed to understand the CSS box model a while ago; so I forced myself to remember as much of CSS as I could
[04:33] <Kinnison> sabdfl: Unfortunately I'm reasonably sure that I forgot how to make spaghetti bolognese in the process
[04:33] <Kinnison> blasted limited-capacity poorly-designed brain
[04:35] <BradB> sabdfl: got a moment to chat about the search widgets?
[04:35] <BradB> sabdfl: namely, i want to know if it's worth the effort to set defaults on the result of the widgets, based on the user's context.
[04:35] <SteveA> sabdfl: the general rule for writing code that interacts with things outside the system is, convert textual data into unicode as soon as you get it.
[04:35] <BradB> because if they're going away, or are going to be modified significantly, it may be wasted effort.
[04:36] <SteveA> sabdfl: or, decide that it is "opaque data", and store it as "bytes" in the database not as text.
[04:36] <sabdfl> SteveA: here's the challenge
[04:36] <sabdfl>  - take several hundred thousand emails in the debbugs system, and import them to the Message table
[04:36] <sabdfl> we have to be able to do this
[04:37] <sabdfl> elmo: what's the ETA on a genuine upload facility that does not require a chinstrap account for hoary uploads?
[04:38] <sabdfl> BradB: if we used wizard-style forms this would be easier, right?
[04:38] <sabdfl> because we get to develop the context over a few page loads
[04:39] <BradB> sabdfl: heck no. that would take too much effort.
[04:41] <elmo> sabdfl: if I go home tonight, I'll should be able to do it tomorrow
[04:41] <sabdfl> elmo: great
[04:41] <BradB> sabdfl: when do we get to see a serious go at a combo box widget that can handle, say, 20,000 items?
[04:41] <sabdfl> thanks!
[04:41] <sabdfl> SteveA: i'm using the std library stuff to parse the emails fine
[04:42] <sabdfl> BradB: it's not going to be possible client-side
[04:42] <sabdfl> BradB: we need either a popup, or a behind-the-scenes query with JS
[04:44] <BradB> sabdfl: ok. it doesn't sound like it's worth it for me to do much more with setting things on the existing widgets then. this widget will be critical for launch. when do we get someone to have a serious go at making a popup that can work for the bug listing screen?
[04:45] <cprov> BradB: thanks
[04:47] <BradB> sabdfl: heck, i think a killer MonsterSelect widget would really help sell launchpad to developers. i for one get a kick out of using apps that do little things that make me go "whoa, now /that/ is neat."
[04:48] <BradB> which is what i did the other day when i saw the combo box thing in bugzilla
[04:48] <sabdfl> BradB: ok, want to have a stab at it?
[04:48] <BradB> sure
[04:49] <sabdfl> my preferred approach is a behind-the-scenes query that returns a JS array
[04:49] <BradB> ok
[04:49] <sabdfl> and keep this all inside the form, in an expanding fieldset
[04:49] <sabdfl> initial state shows search form
[04:49] <sabdfl> enter text and press "find"
[04:50] <sabdfl> fieldset expands to show text search field and list of up to 10 matches
[04:50] <sabdfl> click on a match, and fieldset collapses to show just that selected item, with a "change selection" option to search again
[04:51] <Kinnison> dafydd.
[04:51] <BradB> it needs to handle multi-selects too, of course (a common case in the bug listing)
[04:52] <daf> Daniel.
[04:52] <Kinnison> daf: sleep well?
[04:53] <daf> yes, thank you
[04:57] <carlos> daf: hey!
[04:58] <Kinnison> c'y'all in about 45 mins again
[05:01] <sabdfl> blush... what's the login for foo again?
[05:01] <sabdfl><EMAIL_ADDRESS>test?
[05:01] <carlos> sabdfl: yes
[05:01] <carlos> without the ~
[05:02] <sabdfl> carlos: doesn't work for me
[05:03] <carlos> sabdfl: I think it's only available with sample data
[05:03] <carlos> the dogfood server does not have it
[05:17] <sabdfl> carlos: ah, thanks :-)
[05:20] <BradB> um, why in the HELL am i seeing a bunch of messages like "rm: /mach_kernel: Operation not permitted" when i try to restore a dogfood backup with: bunzip2 -c /Users/bradb/launchpad_dogfood.20041118.sql.bz2 | psql -d launchpad_dev
[05:22] <BradB> rm: /dev: Operation not permitted. um, jesus fuck.
[05:23] <kiko> heh
[05:23] <kiko> dude, that's not good.
[05:24] <daf> !
[05:25] <daf> BradB: you want bunzip2 -cd, surely?
[05:25] <daf> oh, no, never mind
[05:25] <kiko> you redundant welshie
[05:26] <BradB> i saw lots of garbage like "invalid command \n" or "invalid command \N" earlier in the run
[05:26] <BradB> and then this thing starts running launchpad ftests and such, which is thoroughly unexpected.
[05:26] <carlos> BradB: MacOSX is not unix ;-)
[05:27] <carlos> BradB: you just need to execut "ls -l /" to see it
[05:28] <carlos> daf: I'm leaving to go to the university in some minutes, should we talk about anything that cannot wait?
[05:28] <daf> we should
[05:28] <daf> but I don't know of anything that can't wait
[05:28] <kiko> SteveA, yo?
[05:29] <carlos> daf: btw, elmo gave me an account in mawson today so I suppose I could help you with the data import
[05:29] <carlos> daf: ok, I will be back in about 3 hours
[05:29] <daf> carlos: ok, I've been having some problems with the import scripts
[05:30] <carlos> daf: anything else than recent code changes?
[05:31] <daf> mostly database stuff
[05:31] <carlos> daf: ok, will see it when I'm back
[05:31] <carlos> later!
[05:32] <kiko> where's the SteveA
[05:34] <debonzi> SteveA, ping
[05:36] <kiko> dude, it's RAINING.
[05:42] <BradB> eh, didn't i have a .txt file somewhere explaining how to use batching? I wonder if someone removed that.
[05:46] <BradB> sabdfl: hm, i wonder. is it reasonable to require that a launchpad user's browser supports DOM mutation?
[05:47] <BradB> which i guess just means supports DOM...
[05:47] <sabdfl> BradB: what's the coverage of that?
[05:47] <sabdfl> i think LP in lynx would be painful :-)
[05:47] <Kinnison> rehi
[05:47] <sabdfl> kiko: dude, it's POURING over here
[05:47] <sabdfl> and it's dark too
[05:47] <sabdfl> and 16:48
[05:50] <BradB> hm, no idea which browsers don't support DOM, but i guess most do
[05:52] <kiko> ack
[05:52] <kiko> winters in europe.
[05:52] <kiko> BradB, all modern browsers do, but text browsers don't. does that mean no filing bugs from lynx?
[05:54] <BradB> i think that's acceptable.
[05:55] <daf> I thought there was at least one text-based browser that support JavaScript
[05:55] <kiko> links does somewhat.
[05:56] <kiko> I don't know -- Bugzilla has always supported lynx as policy and I've used it on occasion.
[06:03] <elmo> not supporting lynx is CRACK
[06:04] <BradB> i didn't say it wasn't going to be supported, but that i'm ignoring it for now.
[06:04] <kiko> ignoring it for now means ignoring it forever, no?
[06:05] <BradB> yes
[06:05] <daf> so it't not going to be supported?
[06:06] <BradB> heh
[06:22] <SteveA> hi kiko, debonzi, cprov
[06:22] <SteveA> sorry I'm later
[06:22] <kiko> I'm about to skip out, too
[06:23] <kiko> how about we zap through?
[06:23] <debonzi> Hi SteveA
[06:24] <SteveA> ok.
[06:25] <SteveA> in soyuz/distroapp.py there are examples of what is arguably database code
[06:25] <SteveA> for exampe
[06:25] <SteveA>         self.roles=DistroReleaseRole.selectBy(distroreleaseID=self.release.id)
[06:25] <SteveA> that is, rather than use what this method / instance has
[06:25] <SteveA> (in this case, a release)
[06:25] <SteveA> or use stuff got via a utility
[06:26] <SteveA> it is using the database stuff directly.  rather than using operations specified on an interface, it is calling "selectBy" directly.
[06:26] <SteveA> so, it is great that it is there and getting the job done
[06:26] <SteveA> but, I'd like stuff that is this closely linked to the database to be within canonical/launchpad/database/
[06:27] <kiko> let's look at that code
[06:27] <SteveA> It may be that a DistroRelease object needs to grow certain extra methods
[06:27] <SteveA> to allow what this class we're looking at needs
[06:27] <SteveA> that would be one way to fix it
[06:27] <SteveA> I'm looking at class DistroReleaseApp
[06:27] <SteveA> around line 75 in distroapp.py
[06:27] <SteveA> what do you guys think about all this?
[06:29] <kiko> sounds like the right way to go about it
[06:30] <kiko> let me get my tree updated, one moment.
[06:30] <debonzi> SteveA, you mean: I should be a method inside DistroRelease SQLObject that return the selectBy result. right ?
[06:30] <SteveA> one of the reasons I want all the database stuff to be in one place is because I'm working on the advanced security stuff right now.
[06:30] <SteveA> when this is checked in, the most important parts to consider the security of are the database classes
[06:30] <debonzi> s/I/It
[06:31] <kiko> SteveA, we should not use SQLObject-specific API outside of database.py, IMO. Agreed there?
[06:31] <SteveA> debonzi: yes.  so, the DistroReleaseApp code has a reference to a particular DistroRelease object.  It is called 'release'
[06:31] <SteveA> It needs to get the result of calling "DistroReleaseRole.selectBy(distroreleaseID=self.release.id)"
[06:32] <SteveA> so, DistroRelease can grow a method "getRoles" perhaps
[06:32] <SteveA> kiko: I agree.  Not database.py of course, but the database package
[06:32] <kiko> doh, yes, database/*.py.
[06:32] <SteveA> the exception is in stand-alone scripts
[06:32] <kiko> such as gina.
[06:33] <SteveA> yeah
[06:33] <debonzi> SteveA, Is classmethods ok for it too?
[06:33] <kiko> there's not much in the way of a security framework gina can work with anyway, I suspect.
[06:33] <SteveA> debonzi: classmethods are a problem, because they are not really represented in the interface to an object
[06:33] <SteveA> you have to make an assumption about what the object's class is
[06:33] <SteveA> and that breaks the encapsulation
[06:34] <SteveA> so, the public api should be instance methods, described by interfaces
[06:34] <kiko> I dislike classmethods personally
[06:34] <kiko> in this case there is a good reason not to use one too (self.release.id)
[06:34] <SteveA> note that we're working with interfaces
[06:34] <SteveA> an interface doesn't really say whether something is implemented by an instance method or a class method or what
[06:34] <SteveA> but, seeing as we have a release object, and that object is an instance
[06:35] <SteveA> it is natural to use instance methods to implement the operations needed by the interface
[06:35] <SteveA> does that make sense?
[06:35] <kiko> yes, though there are some weird exceptions in SourcePackage. I'd need to look at that code carefully.
[06:36] <SteveA> if it makes enough sense for the majority of the code, we can convert that to the new way, and look again at any weird things
[06:36] <kiko> my tree is bonkers :-/
[06:36] <kiko> yes, indeed.
[06:36] <SteveA> There is something odd with my tree at the moment I think.  I'm getting a test that always fails, and a test that always hangs.
[06:36] <kiko> this is the way we should go, for sure
[06:36] <SteveA> but I can still merge into RF
[06:37] <kiko> I can't star-merge, I get bucketloads of conflicts and no undo love.
[06:37] <kiko> SteveA, did you get my Zope patch from salgado?
[06:37] <SteveA> I did
[06:37] <SteveA> I read the email, but I haven't thought about it yet
[06:37] <kiko> okay. it's really trivial -- and follows what the code does in that part anyway.
[06:39] <SteveA> ok
[06:39] <SteveA> I'll think about it soon
[06:39] <SteveA> so, who is going to do what with the database code in the soyuz package?
[06:39] <kiko> debonzi and I can handle it
[06:40] <kiko> (if my tree unfuxors itself)
[06:40] <SteveA> ok, cool.  when can you start?
[06:41] <SteveA> daf: around?
[06:42] <daf> SteveA: yes
[06:43] <kiko> SteveA, lemme check current statuspile
[06:43] <SteveA> can we have a chat about rosetta stuff?  did you read what carlos and I talked about earlier today?
[06:43] <daf> I did
[06:43] <SteveA> any comments?
[06:43] <kiko> SteveA, starting monday we can do a review and rehack of these bits
[06:44] <kiko> SteveA, if you want some of it done tomorrow, we can drop the ball on other things
[06:45] <daf> SteveA: I've been working on the import, but have been having problems with the import script which mean it is not done yet
[06:45] <SteveA> kiko: it can be done on monday.
[06:45] <kiko> okay, scheduled
[06:45] <debonzi> SteveA, nice
[06:45] <SteveA> thanks guys
[06:45] <SteveA> daf: what's up?
[06:45] <kiko> debonzi, can you file a bug for me while I unfutz my tree
[06:45] <debonzi> kiko, yep
[06:45] <kiko> thanks.
[06:45] <daf> well, there were some database changes which the scripts hadn't been updated to reflect
[06:46] <daf> and now I am getting error messages which I am still in the process of diagnosing
[06:47] <SteveA> can anyone help you with this?
[06:48] <daf> Carlos might be able to, but he isn't around at the moment
[06:49] <SteveA> can you describe what the first problem is in some more detail?
[06:50] <cprov> BradB: finally something good, do you have time to analize the results of my task ?
[06:50] <daf> Traceback (most recent call last):
[06:50] <daf>   File "./poimport.py", line 168, in ?
[06:50] <daf>     options.potemplate, options.language, True)
[06:50] <daf>   File "./poimport.py", line 95, in update_stats
[06:50] <daf>     poFile = poTemplate.poFile(languageCode)
[06:50] <daf>   File "/home/daf/launchpad-devel/launchpad/lib/canonical/launchpad/database/pofile.py", line 263, in poFile
[06:50] <daf>     raise KeyError, language_code
[06:50] <daf> KeyError: "Couldn't find record in database"
[07:08] (SteveA/#launchpad) daf: do what you think will work best.  but definitely use the debugger
[07:09] (SteveA/#launchpad) is the language table in dogfood the same as the one in rosetta alpha
[07:09] (SteveA/#launchpad) ?
[07:09] (daf/#launchpad) yes, probably
[07:09] (daf/#launchpad) I'll try reporoducing it on my machine
[07:10] (SteveA/#launchpad) why not do a query, and check that they are in fact the same?
[07:10] (SteveA/#launchpad) you have access to both databases
[07:12] <fabbione> ping
[07:12] <fabbione> ok
[07:12] <fabbione> sorry for the introdusion :-)
[07:12] <fabbione> introsion
[07:26] (BradB/#launchpad) damn, looks like i'll be reinstalling. the db restore done verbatim as describe in the email to lp@ blew away all my applications.
[07:26] (kiko/#launchpad) that's crazy
[07:27] (kiko/#launchpad) how did that happen?
[07:27] (BradB/#launchpad) not the faintest clue...
[07:27] (daf/#launchpad) crazy!
[07:50] (lulu/#launchpad) night all :o)
[07:51] (elmo/#launchpad) quick hands up, who's still working?
[07:51] (elmo/#launchpad) seriously, I need to reboot some of the remaining boxes,including mawson, macquarie and emperor - any objections if I do it now?
[07:51] (kiko/#launchpad) me
[07:51] (kiko/#launchpad) not me
[07:59] (daf/#launchpad) elmo: hmm, should be OK, I think
[08:06] (kiko/#launchpad) daf, what does it mean when tla update sits for hours writing to unlinked files in /tmp?
[08:07] (daf/#launchpad) I don't know
[08:07] (daf/#launchpad) sounds pretty broken, though
[08:07] (kiko/#launchpad) time to nuke my tree?
[08:07] (daf/#launchpad) hmm, perhaps
[08:08] (daf/#launchpad) try asking somebody who knows tla better first, maybe
[08:10] (kiko/#launchpad) hmmm
[08:16] <carlos> hi
[08:21] (elmo/#launchpad) mawson rebooting
[08:27] (kiko/#launchpad) * searching ancestor revision in library in archive<EMAIL_ADDRESS>[08:27] (kiko/#launchpad) corrupt library (failed inode signature validation)
[08:27] (kiko/#launchpad)     archive<EMAIL_ADDRESS>[08:27] (kiko/#launchpad)     revision: launchpad--devel--0--patch-229
[08:27] (kiko/#launchpad) this is lots of fun!
[08:27] (daf/#launchpad) lies! lies!
[08:28] <carlos> kiko: :-P
[08:29] <carlos> daf: ;-)
[08:29] (kiko/#launchpad) hmmm
[08:29] <carlos> daf: I will be available to talk in about 15 minutes, is it ok for you?
[08:29] (kiko/#launchpad) interesting, it's refueling my revlibs
[08:29] (daf/#launchpad) carlos: ok
[08:34] (elmo/#launchpad) macquarie/emperor
[08:34] (elmo/#launchpad) + done
[08:35] (kiko/#launchpad) whee
[08:38] (kiko/#launchpad) SteveA, ping?
[08:38] (kiko/#launchpad) daf, do you know why psycopgda and sqlos aren't links to sourcecode?
[08:39] (kiko/#launchpad) or SteveA?
[08:39] (kiko/#launchpad) or carlos
[08:39] (kiko/#launchpad) or anyone else
[08:40] (kiko/#launchpad) Kinni!
[08:40] (daf/#launchpad) kiko: because they are not compiled?
[08:41] (kiko/#launchpad) hmmm
[08:41] (kiko/#launchpad) is that the only reason? is it a good one?
[08:42] (daf/#launchpad) I think it's reasonable
[08:42] (daf/#launchpad) I don't see any major disadvantages
[08:43] (elmo/#launchpad) it's CRACK
[08:43] (daf/#launchpad) elmo: ?
[08:44] (elmo/#launchpad) it's the same CRACK as people who copy library source into their own projects rather than just linking with it
[08:44] (kiko/#launchpad) it's bizarre to me -- I always need to special-case psycopgda and sqlos into the directory.
[08:44] (elmo/#launchpad) CRACK CRACK CRACK
[08:44] (daf/#launchpad) elmo: they are in separate arch categories
[08:45] (elmo/#launchpad) daf: is psycopg modified at all?
[08:46] (elmo/#launchpad) if not - WTF is it in there?
[08:46] (daf/#launchpad) not psycopg
[08:46] (daf/#launchpad) psycopgda
[08:47] (kiko/#launchpad) I'm more curious about the consistency issue that arises from having bits in sourcecode and bits in lib
[08:47] (kiko/#launchpad) linked to sourcecode
[08:47] (kiko/#launchpad) and other bits not linked
[08:47] (kiko/#launchpad) ugh
[08:47] (daf/#launchpad) consistency is good
[08:47] (sabdfl/#launchpad) BradB|lunch: how do you mean, blew away your applications?
[08:47] (sabdfl/#launchpad) i've found that working with a backup of the dogfood db on my local machine i need to make sure
[08:48] (sabdfl/#launchpad) that i apply the patches to bring the db schema in line with my code
[08:48] (sabdfl/#launchpad) SELECT * FROM launchpaddatabaserevision;
[08:48] (sabdfl/#launchpad) then apply the patches needed to bring the revision up to the level of your code
[08:49] (kiko/#launchpad) daf, in this case, apparent lack of consistency :)
[08:49] (daf/#launchpad) well, if you can fix it, I say go ahead
[08:50] (kiko/#launchpad) I'd move sqlos and psycopgda into sourcecode and link it too. wouldn't you?
[08:53] (kiko/#launchpad) corrupt library (failed inode signature validation)
[08:53] (kiko/#launchpad)     archive<EMAIL_ADDRESS>[08:53] (kiko/#launchpad)     revision: launchpad--devel--0--patch-302
[08:53] (kiko/#launchpad) You should remove this revision from your library.
[08:53] (kiko/#launchpad) whee!
[08:54] (sabdfl/#launchpad) wow#
[08:54] (sabdfl/#launchpad) did you know you can tla add a file that does not exist?
[08:54] (sabdfl/#launchpad) and it works?
[08:54] (daf/#launchpad) which definiton of "works" are we using here?
[08:54] (elmo/#launchpad) guys - chinstrap's going down - anyone need it desperately right now ?
[09:00] <carlos> elmo: as soon as it's back soon... ;-)
[09:00] <carlos> daf: I'm ready to talk
[09:01] (elmo/#launchpad) carlos: it's back...
[09:01] <carlos> elmo: perfect, thanks
[09:07] (kiko-fud/#launchpad) lifeless, the email to launchpad is probably one of those you'll say "bah, that's easy" I suspect
[09:16] (SteveA/#launchpad) kiko-fud: we agreed in a launchpad meeting a while ago that these things were going to move into "sourcecode" and out of "launchpad/lib"
[09:17] (SteveA/#launchpad) I never got around to it.  Thanks for bringing it up now.
[09:17] (lifeless/#launchpad) sabdfl: can't do that in baz :)
[09:17] (lifeless/#launchpad) sabdfl: why are u not using baz ?
[09:17] (lifeless/#launchpad) :)
[09:18] (SteveA/#launchpad) daf: how are the imports going?
[09:19] (daf/#launchpad) still trying to reproduce the error on my machine
[09:19] (daf/#launchpad) I have an import running right now
[09:22] (SteveA/#launchpad) did you investigate the error on the server, so that you know exactly what the problem is?
[09:23] (daf/#launchpad) no
[09:23] (SteveA/#launchpad) it would be good to do that -- work out exactly what is wrong on the server.  fix and test on your machine.  that's my suggestion.
[09:23] (SteveA/#launchpad) you can't expect to solve a problem until you know what is wrong.
[09:24] (SteveA/#launchpad) is this something where I can help you, via screen ?
[09:24] (daf/#launchpad) I dont't know how I can test it on my machine before I can get it to fail on my machine
[09:25] (SteveA/#launchpad) it will be easy to get it to fail on your machine once we know exactly what is failing
[09:26] (BradB/#launchpad) sabdfl: in OS X, each user has some kind of copy in their home dir (in ~/Library/Applications or ~/Applications or something) of the apps they install. those all got blown away.
[09:26] (sabdfl/#launchpad) bradb: by what?
[09:26] (BradB/#launchpad) elmo: do netgear 802.11g cards work in powerbooks?
[09:26] (BradB/#launchpad) sabdfl: rm :)
[09:26] (sabdfl/#launchpad) ah
[09:26] (sabdfl/#launchpad) by one of our scripts?
[09:26] (BradB/#launchpad) sabdfl: from following the instructions verbatim to restore a dogfood db
[09:26] (sabdfl/#launchpad) oops
[09:27] (elmo/#launchpad) BradB: I don't know - it's just whether they work on Linux tho - not powerbook specific
[09:27] (BradB/#launchpad) elmo: what do you use?
[09:27] (elmo/#launchpad) cisco aironet
[09:27] (SteveA/#launchpad) elmo: have you prodded the ftp server yet?
[09:28] (elmo/#launchpad) $$$ tho, and it's not 100% on Linux/PowerPC
[09:28] (elmo/#launchpad) SteveA: no, been at the DC all day
[09:28] (elmo/#launchpad) I'll look at it tomorrow, when I'm home
[09:28] (SteveA/#launchpad) ok.  let me know if you have questions about it.
[09:28] (SteveA/#launchpad) daf: I really want the rosetta imports fixed soon. consider me to be at your disposal to help get it sorted, until I go to sleep tonight.
[09:29] (elmo/#launchpad) BradB: looks like modern WG511 uses Atheros chipset, which is the same as the onboard one on modern powerbook's, which means BZZT
[09:29] (elmo/#launchpad) bradb: (btw, by not 100% don't get me wrong, it works just fine for me, but some features are missing, like the ability to hot plug the card :)
[09:30] (elmo/#launchpad) stevea: will do
[09:30] (BradB/#launchpad) elmo: ah
[09:30] (BradB/#launchpad) hmph
[09:30] (elmo/#launchpad) BradB: mark has some card that limi got working that isn't cisco
[09:31] (elmo/#launchpad) (s/got working/'just works in warty' apparently)
[09:31] (BradB/#launchpad) the place i bought it from mentioned sommet
[09:31] (elmo/#launchpad) I don't recall what  it is tho
[09:31] (BradB/#launchpad) s/bought it/bought my powerbook/
[09:31] (BradB/#launchpad) sabdfl: did you try the store instructions in linux?
[09:32] (daf/#launchpad) SteveA: if I get stuck, I will ask for help
[09:32] (BradB/#launchpad) sabdfl: see, what was really fux0red is that in doing this restore, it ran the test suite more than once too...did all kinds of bizarre things, including blowing away my Applications folder on OS X. I don't even have a bloody terminal anymore, and sshd ain't running, so i can't come in from the outside.
[09:33] (SteveA/#launchpad) daf: I'd like to get involved, and understand what's going on, so I'm ready to help when needed.  what do you think of setting up a screen session?
[09:33] (daf/#launchpad) well, I think I just found the cause of the problem
[09:35] (SteveA/#launchpad) cool!
[09:37] (daf/#launchpad) carlos: around?
[09:43] <carlos> daf: yes
[09:45] (daf/#launchpad) can we discuss POFile.updateStatistics?
[09:47] <carlos> sure
[09:47] (BradB/#launchpad) elmo: can i use my pbg4's not-wireless internet card fine in ubuntu?
[09:48] <carlos> daf: what happens there?
[09:48] <carlos> BradB: the ethernet ?
[09:48] <carlos> BradB: it works here
[09:48] (elmo/#launchpad) BradB: the wired port?  sure
[09:48] <carlos> BradB: the only problem with new powerbooks is the bradcom wireless
[09:49] (elmo/#launchpad) carlos: and the modem
[09:49] <carlos> elmo: well, I never remember the modem...
[09:49] (elmo/#launchpad) but yeah they got suspend/resume now \o/
[09:49] <carlos> elmo: isn't there a driver to use it?
[09:49] <carlos> a propietary one, I know
[09:49] (BradB/#launchpad) well, the machine i'm on is completely hosed. if i close this instance of x-chat i won't be able to reopen it.
[09:49] (elmo/#launchpad) carlos: only for i386 AFAIK
[09:49] (BradB/#launchpad) everything blown away, can't even send bloody mail anymore.
[09:50] (BradB/#launchpad) going over to other machine to burn warty, which i downloaded while i was out for lunch
[09:50] <carlos> elmo: oh, I thought they are for ppc machines...
[09:51] (daf/#launchpad) carlos: first of all, I'm not clear on the newImport flag
[09:51] (daf/#launchpad) carlos: can you try explaining it to me?
[09:53] <carlos> daf: ?
[09:53] (daf/#launchpad) s/flag/parameter/
[09:54] <carlos> daf: without it, the "current" count will be broken
[09:54] <carlos> because it will take in account the msgsets that where moved from fuzzy to "complete"
[09:55] <carlos> or the ones that were moved from untranslated to fuzzy or  complete
[09:55] (daf/#launchpad) hmm, you're saying things, but my brain is not working
[09:55] <carlos> with it we can control that it will only change when we are importing a new pofile
[09:55] <carlos> daf: X-)
[09:55] <carlos> blah, blah, blah, blah...
[09:56] <carlos> daf: should I improve the explanation?
[09:56] <carlos> or just wait for your brain?
[09:56] (daf/#launchpad) what does "current" mean?
[09:56] <carlos> pofile.current
[09:57] <carlos> the number of translated strings in last .po import
[09:57] (daf/#launchpad) biab, workraving
[09:58] <carlos> ok
[10:15] (daf/#launchpad) let's try again
[10:16] (daf/#launchpad) so, we have thre states?
[10:16] (daf/#launchpad) current, updated, rosetta?
[10:16] <carlos> yep
[10:17] <carlos> and updated is not working correctly with current schema (or I don't know how to fix it)
[10:17] <carlos> current == translated messages from latest .po imported
[10:17] (daf/#launchpad) oh, is there a bug open about that?
[10:17] <carlos> updated == messages that were already translated but were updated from rosetta
[10:18] <carlos> rosetta == messages that were fuzzy or untranslated and we finished them from rosetta (and they were not imported again with a new po import)
[10:18] <carlos> daf: no, I just noticied after read my comment in the code
[10:18] (daf/#launchpad) and these states are mutually exclusive?
[10:18] <carlos> no
[10:19] <carlos> current and rosetta are
[10:19] <carlos> current and updated are not
[10:19] <carlos> hmm
[10:19] <carlos> sorry
[10:19] <carlos> forget that
[10:19] <carlos> yes, the states are mutually excusive
[10:19] (daf/#launchpad) ok, could you add a comment saying so?
[10:19] <carlos> a updated string cannot be in rosetta
[10:20] <carlos> daf: in the fields declaration or in the updateStatistics method?
[10:20] (daf/#launchpad) either, both
[10:20] <carlos> ok
[10:20] (daf/#launchpad) the code, for sure
[10:20] <carlos> I think it's defined in the interface
[10:20] <carlos> let me check
[10:21] (daf/#launchpad) or perhaps we should have more comprehensive documentation about statistics separately
[10:23] <carlos> def currentCount(language=None):
[10:23] <carlos>         """Returns the number of msgsets matched to a potemplate for this
[10:23] <carlos>         project that have a non-fuzzy translation in its PO file for this
[10:23] <carlos>         language when we last parsed it."""
[10:23] <carlos>     def updatesCount(language=None):
[10:23] <carlos>         """Returns the number of msgsets for this project where we have a
[10:23] <carlos>         newer translation in rosetta than the one in the PO file for this
[10:23] <carlos>         language, when we last parsed it."""
[10:23] <carlos>     def rosettaCount(language=None):
[10:23] <carlos>         """Returns the number of msgsets where we have a translation in rosetta
[10:23] <carlos>         but there was no translation in the PO file for this language when we
[10:23] <carlos>         last parsed it."""
[10:24] (daf/#launchpad) ok, I'm still trying to grasp this parameter
[10:25] <carlos> the main idea is
[10:25] (daf/#launchpad) when do you use it, when do you not use it?
[10:25] <carlos> when you import a new pofile, the numbers could change a lot
[10:25] <carlos> it's used only when you import a new pofile
[10:26] (daf/#launchpad) as opposed to?
[10:26] <carlos> when you translate from rosetta and add a new string
[10:26] (daf/#launchpad) is it an optimisation?
[10:26] <carlos> so you only need to recalculate updates and rosetta
[10:26] <carlos> no
[10:27] <carlos> in fact I don't think it should be called if it's not after an import
[10:27] <carlos> I mean
[10:27] <carlos> that method should only called after a new import
[10:27] <carlos> or if the statisticis cache could be out of sync
[10:27] (daf/#launchpad) what happens if you call it and you haven't done an import?
[10:27] <carlos> in which case the argument you don't like comes in the game
[10:28] <carlos> if the argument tells you that it's not an import
[10:28] (daf/#launchpad) well, I'm not sure whether I don't like it yet, I need to understand it first :)
[10:28] <carlos> the updates and rosetta fields will be updated
[10:28] <carlos> the current field will remain the same because there were not new imports
[10:28] (daf/#launchpad) so it is an optimisation?
[10:29] <carlos> the method itself no
[10:29] <carlos> the fields, yes
[10:29] (daf/#launchpad) I mean the parameter
[10:29] <carlos> why?
[10:29] <carlos> if you execute it without a poimport the values will be broken
[10:29] (daf/#launchpad) well, you are trying to save some work by not always recalculating the current field, right?
[10:30] <carlos> no
[10:30] (daf/#launchpad) oh
[10:30] <carlos> you cannot calculate the current field when you get a new translation from rosetta
[10:30] (daf/#launchpad) why not?
[10:30] <carlos> because the information is lost
[10:30] <carlos> (the fuzzy flag)
[10:31] <carlos> you cannot know if it was fuzzy or untranslated
[10:31] <carlos> that's why I suggested to move the fuzzy flag from msgset to the sighting
[10:31] (kiko/#launchpad) SteveA, should I file a bug on you?
[10:31] <carlos> so we don't lose that information
[10:31] (daf/#launchpad) ok, I didn't realise that
[10:31] <carlos> well, we could lose it that why also
[10:32] <carlos> but it's less usual
[10:32] <carlos>  /s/why/way/
[10:32] (daf/#launchpad) don't we have information on the origin of a translation?
[10:32] <carlos> not really
[10:32] <carlos> you add a new translation from rosetta
[10:32] <carlos> then export a po file
[10:32] <carlos> and reimport it again
[10:32] <carlos> the origin will be rosetta
[10:33] <carlos> but it was in the po file
[10:33] (daf/#launchpad) argh
[10:33] <carlos> daf: funny, isn't it?
[10:33] <carlos> :-)
[10:33] (daf/#launchpad) this is annoying :(
[10:33] (SteveA/#launchpad) kiko: sure, thanks
[10:34] <carlos> daf: do you want I work on a proposal so we don't lose any information?
[10:34] (daf/#launchpad) hmmm
[10:38] (daf/#launchpad) I don't like the fact that I have a hard time understanding our database code
[10:38] (daf/#launchpad) I would like to fix that
[10:38] (daf/#launchpad) not just the code, but the schema also
[10:39] <carlos> daf: the dia image is a good start point
[10:39] (daf/#launchpad) well
[10:39] <carlos> but I think it's obsoleted, we should update it
[10:39] (daf/#launchpad) that's a good conceptual view
[10:39] (daf/#launchpad) but if I want to know "how are statistics updated?", it's not much use
[10:40] <salgado> lifeless, rsyncing worktrees will trigger that "corrupt library" error because of the pristine tree located inside it, right?
[10:40] (daf/#launchpad) carlos: ok, let's sidetrack for a moment
[10:40] (daf/#launchpad) when you import a PO template, how are statistics updated?
[10:40] (lifeless/#launchpad) you will only have pristines inside a working tree if you don't have a greedy revlib, and everyone should have a greedy, sparse, revlib.
[10:40] <carlos> daf: well, we don't have a policy about how to update the statistics...
[10:41] (daf/#launchpad) what do you mean by "policy"?
[10:41] <carlos> daf: we need to define that procedure
[10:41] (daf/#launchpad) I mean
[10:41] <carlos> daf: I just finished the script lalo started
[10:41] (daf/#launchpad) is there a function somewhere that updates the statistics for a template?
[10:41] <carlos> that does not mean we have documented or defined a way to update the statistics
[10:42] <carlos> daf: no
[10:42] (daf/#launchpad) ok
[10:42] <carlos> daf: and now that you talk about it...
[10:42] <carlos> daf: is not doable with the current schema
[10:43] <salgado> lifeless, ok, so i'll have no problems. I already have sparse and greedy revlibs
[10:44] (daf/#launchpad) lifeless: "{tla,baz} get" doesn't create a pristine if the revision you're getting is in the revlib?
[10:44] (lifeless/#launchpad) right
[10:44] (daf/#launchpad) carlos: why not?
[10:45] (lifeless/#launchpad) and if the revlib is greedy, it will add it to the revlib rather than making a pristine in the project tree.
[10:45] (daf/#launchpad) carlos: same sort of problem as before?
[10:45] <carlos> daf: yes, I just noticied it
[10:46] <carlos> daf: if we don't have the original data that was imported, the current value cannot be updated
[10:46] (daf/#launchpad) hmm
[10:47] (daf/#launchpad) hmm, rosetta-states.dia is a good idea, but I think it needs updating
[10:47] <carlos> rosetta-states?
[10:47] <carlos> what's that?
[10:48] (daf/#launchpad) lib/canonical/rosetta/docs/rosetta-states.dia
[10:49] <carlos> yep, it should be updated with more info
[10:49] (daf/#launchpad) suggestion: we have an RST or DocBook document in docs/ which has information on this sort of thing
[10:49] (daf/#launchpad) of course, it'll only work if we keep it up to date :)
[10:50] (daf/#launchpad) but we have some documentation in the wiki, and we have some documentation in docs/
[10:50] (daf/#launchpad) it would be good to bring it together
[10:50] (daf/#launchpad) so we can have cross-references
[10:51] <carlos> I don't know anything about RST
[10:51] (daf/#launchpad) DocBook?
[10:51] <carlos> so we move from wiki to docs/?
[10:51] <carlos> daf: yes, I know docbook
[10:51] (daf/#launchpad) yeah, me too
[10:51] (daf/#launchpad) RST is very simple, though
[10:52] (daf/#launchpad) yeah, I like the idea of keeping the docs and the code close together
[10:52] <carlos> daf: what do you think that fits better to our needs
[10:52] (daf/#launchpad) it's easier to update both at the same time, then
[10:52] <carlos> I don't have any problem learning new formats
[10:52] (daf/#launchpad) I think either format would work
[10:52] (daf/#launchpad) my personal preference is for DocBook
[10:52] <carlos> same here
[10:52] <carlos> docbook with xml templates
[10:52] (daf/#launchpad) ok, let's open a bug on this
[10:53] (daf/#launchpad) ah, except Malone is down
[10:53] (daf/#launchpad) I'll do it later
[10:53] <carlos> is down?
[10:53] (daf/#launchpad) yeah, maybe it didn't come back after the reboot
[10:54] <carlos> right, the reboot
[10:54] <carlos> :-)
[10:55] <salgado> lifeless, is it possible to share a revlib between multiple arch users, using baz?
[10:55] (daf/#launchpad) BradB|osx: who can bring the dogfood back up?
[10:56] (lifeless/#launchpad) yes and no. if the permissions on your files allows it, and you don't hit race conditions, them yes. but its not guaranteed, and not supported.
[10:56] (kiko/#launchpad) BAZ ROX
[10:56] (kiko/#launchpad) hmmm
[10:56] <salgado> kiko, so, I think it's not a good idea
[10:57] (kiko/#launchpad) lifeless, will it ever be supported? it would mean significant savings for us..
[10:57] (lifeless/#launchpad) kiko: its not possible in general. So supporting it is hard.
[10:57] (lifeless/#launchpad) its not possible because...
[10:57] (lifeless/#launchpad) say I have a file thats mode 0700.
[10:57] (lifeless/#launchpad) its in my revlib with that mode. Now, HTF can that be shared ?
[10:58] (kiko/#launchpad) I see.
[10:59] (daf/#launchpad) hmm, so it would only be possible if the on-disk permissions were separate from the revision permissions
[10:59] (kiko/#launchpad) you'd need some intelligent revlib service.
[10:59] (daf/#launchpad) well, it could be quite dumb
[10:59] <carlos> daf: ok, returning to more urgent things... can I help you with the pot/po imports?
[10:59] (kiko/#launchpad) from which you requested the files and then synthesized them into the correct perms.
[10:59] (daf/#launchpad) carlos: once I fix this bug in poimport.py, probably
[11:00] (daf/#launchpad) carlos: the bug is: it calls update_stats() when language is None
[11:00] <carlos> hmm
[11:00] <carlos> really?
[11:00] (daf/#launchpad) yeah
[11:00] <carlos> let me check I don't forgot to deactivate some "debug" changes I did...
[11:01] (lifeless/#launchpad) kiko: its doable, but it makes it a lot more complex, even for the dumb case. That said, we have to do some stuff in this area anyway, I'll certainly try not to make it worse than it is.
[11:01] <carlos> daf: ok, my fault, I forgot to commit a fix for that
[11:01] (daf/#launchpad) yeah?
[11:02] (daf/#launchpad) there are a few changes I'd like to make to that script
[11:02] <carlos> daf: could you check it this way?:
[11:02] <carlos> print "Importing %s ..." % options.file
[11:02] <carlos>             bridge.imports(person, in_f, options.project, options.product,
[11:02] <carlos>                            options.potemplate, options.language)
[11:02] <carlos>             if options.language is not None:
[11:02] <carlos>                 print "Updating %s pofile for '%s'..." % (
[11:02] <carlos>                     options.potemplate, options.language)
[11:02] <carlos>                 bridge.update_stats(options.project, options.product,
[11:02] <carlos>                                     options.potemplate, options.language, True)
[11:02] (daf/#launchpad) ah, looks good
[11:03] <carlos> daf: will you commit that change or should I do it?
[11:03] (daf/#launchpad) well, easier for you to do it, I think
[11:04] (daf/#launchpad) so go ahead
[11:04] <carlos> ok
[11:04] <BradB|osx> daf: stub
[11:04] (daf/#launchpad) garh
[11:04] (daf/#launchpad) we need to serviceify launchpad
[11:05] <BradB|osx> i've already filed a bug on that (at least the part about making it run gracefully as a deamon)
[11:06] (daf/#launchpad) groovy
[11:11] <carlos> daf: merge request sent
[11:11] (daf/#launchpad) thanks
[11:13] (daf/#launchpad) SteveA: there's a class here that inherits from PlacelessSetup -- what does that mean?
[11:22] (SteveA/#launchpad) where is "here" ?
[11:22] (SteveA/#launchpad) PlacelessSetup is a mixin class used in zope3 unit tests
[11:22] (daf/#launchpad) in lib/canonical/rosetta/scripts/poimport.py
[11:23] (SteveA/#launchpad) it sets up and tears down the framework such as the adapters service and utilities services
[11:23] (daf/#launchpad) this class is not calling its superclass's __init_ or anything
[11:23] (SteveA/#launchpad) that code is a mess
[11:24] (daf/#launchpad) yes :(
[11:24] (SteveA/#launchpad) at first glance, the PlacelessSetup is a decoy
[11:25] (daf/#launchpad) ok, I'll try removing it and seeing if it still works
[11:25] (SteveA/#launchpad) also,
[11:25] (SteveA/#launchpad) move all of the stuff in the if __name__ == '__main__': section at the end into a main() function
[11:25] (daf/#launchpad) I don't see the point of the exception munging either
[11:25] (SteveA/#launchpad) then split out the option parsing part into a parse_options() part
[11:25] (daf/#launchpad) yes, good idea
[11:25] (daf/#launchpad) I don't want to make too many changes before I've merged carlos's changes to this file
[11:26] (SteveA/#launchpad) ok
[11:26] (daf/#launchpad) (which should allow imports to work again)
[11:26] (SteveA/#launchpad) and it should be formatted more like pop8
[11:26] <carlos> daf: it's a trivial change, so it should not be too difficult
[11:26] (SteveA/#launchpad) pep8
[11:26] (daf/#launchpad) what formatting is lax?
[11:27] (SteveA/#launchpad) line 42 is too long
[11:27] (SteveA/#launchpad) line 46 is a mess
[11:27] (daf/#launchpad) right
[11:27] (SteveA/#launchpad) another issue is the try:except: around line 46
[11:27] (SteveA/#launchpad) it is around way too much
[11:28] (SteveA/#launchpad) it should be around the absolute minimum
[11:28] (daf/#launchpad) I'm thinking of getting rid of the try/except completely
[11:28] (SteveA/#launchpad) and even better, it shoudl use a check of the length of the results
[11:28] (SteveA/#launchpad) rather than half expecting an index error
[11:28] (SteveA/#launchpad) just sloppy programming
[11:29] (SteveA/#launchpad) lines 61 onwards -- bad formatting
[11:29] (SteveA/#launchpad) not sure what it's doing in the except: clause anyway
[11:29] (SteveA/#launchpad) and incoprehensible XXX comments
[11:30] (SteveA/#launchpad) there's more, but I'll stop there
[11:31] (SteveA/#launchpad) ok, so you reckon that when you're done with fixing this code, you can do the imports
[11:31] (SteveA/#launchpad) and the dogfood stuff will be done
[11:31] (daf/#launchpad) and the virtual hosting
[11:31] (SteveA/#launchpad) ok
[11:32] (SteveA/#launchpad) great
[11:33] (SteveA/#launchpad) I must go to sleep now.  please send me an email to let me know how it goes
[11:33] <carlos> SteveA: night
[11:33] <carlos> daf: if you are going to improve the script, could you do it in a way I could use importing it from other scripts?
[11:34] (daf/#launchpad) SteveA: sure, thanks
[11:34] (daf/#launchpad) carlos: yeah, I like that
[11:34] <carlos> daf: thanks
[11:38] (daf/#launchpad) hmm, the merge seems to be taking a long time...
[11:38] <carlos> it was just a line change...
[11:39] (daf/#launchpad) lifeless: did PQM come back up after the reboot?
[11:40] <carlos> daf: the merge is done here
[11:40] <carlos> I got the confirmation mail
[11:40] (daf/#launchpad) ah
[11:40] <carlos> I thought you were talking about the star-merge
[11:41] (daf/#launchpad) did dilys announce it?
[11:41] <carlos> daf: I don't think so
[11:41] (daf/#launchpad) grr
[11:42] (lifeless/#launchpad) daf: pqm is cron based, it always comes up
[11:42] <carlos> daf: dilys needs some love, he miss you since you went to NY :-P
[11:42] (daf/#launchpad) carlos: heh
[11:42] (daf/#launchpad) I'll spend some time with her later
[11:42] (daf/#launchpad) I'm going out right now
[11:43] (daf/#launchpad) I'll carry on working on the imports later
[11:43] <carlos> daf: could you CC: to me the mail about the import status?
[11:43] (daf/#launchpad) sure
[11:43] (daf/#launchpad) later!
[11:43] <carlos> Steve always asks me but I don't know what to answer because I go to sleep
[11:43] <carlos> daf: thanks
[11:43] <carlos> daf: later!