[00:03] <lifeless> wgrant: what do you think? closable?
[00:03] <wgrant> lifeless: Needs testing. If it's not closable, then it's a security bug.
[00:03]  * spm needs to fix his losa highlight. "closable" shoudn't be a highlighter....
[00:03] <lifeless> how about closeable?
[00:04] <wgrant> lifeless: It's possibly from back in the days when one got notified of duplicates of the master bug if one was subscribed to a duplicate.
[00:04] <lifeless> :P
[00:04] <spm> ha
[00:04] <lifeless> wgrant: yes, its old; thus my question ;)
[01:08] <lifeless> wgrant: are you on launchpad-security now?
[01:08] <lifeless> wgrant: if not that would explain your confusion when I mentioned the bug before
[01:09] <wgrant> lifeless: I have been for a while.
[01:09] <wgrant> I get launchpad security mail.
[02:18] <lifeless> sinzui: I guess you're off to family time, just saw your reply to my review; if you do want to discuss it now, I'd be delighted
[02:18] <lifeless> otherwise, if I don't hear from you I'll reply as much as I can think of via mail and look for you my morning tomorrow
[02:36] <lifeless> hmm
[02:36] <lifeless> where are my daily oops reports for prod :(
[02:47] <lifeless> no landings to devel since tuesday? wtf
[02:49] <poolie> hi lifeless
[02:49] <lifeless> hiya
[02:51] <poolie> shall we talk now? pots?
[02:51] <poolie> schooners?
[02:52] <lifeless> sure
[02:53] <lifeless> skype is easiest for me
[02:57] <poolie> lifeless, https://bugs.launchpad.net/bugs/739772
[02:57] <_mup_> Bug #739772: Question should be available via the API <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/739772 >
[03:51] <lifeless> jcsackett: you're going to hate me :)
[03:52] <lifeless> jcsackett: https://bugs.launchpad.net/launchpad/+bug/741440
[03:52] <_mup_> Bug #741440: merge proposal diff only shows once per page load <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/741440 >
[04:16] <LPCIBot> Project windmill build #96: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill/96/
[04:18] <StevenK> Windmill, you make me sad.
[04:19] <StevenK> Actually, gina's doctest makes me positively suicidal.
[04:34] <StevenK> I think I broke it, gina has been running for 11 minutes.
[04:35] <StevenK> No, it's just OOPSing constantly
[04:40] <wgrant> :( fake forms
[04:44]  * StevenK burns gina.txt, and then douses it with kerosene.
[04:46] <wgrant> Watch out for gina-multiple-arch.txt
[04:46] <wgrant> It may avenge its brother.
[04:56] <StevenK> Haha
[04:57] <StevenK>   Ran 1 tests with 1 failures and 0 errors in 18 minutes 25.669 seconds.
[04:57] <lifeless> ok, time to write more deploy scripts
[05:10] <wgrant> Hmm. Lots of theme updates.
[05:10] <wgrant> New Ubuntu panel logo, new speaker icons, messaging indicate is now blue...
[05:10] <wgrant> Wallpaper is... very slightly different.
[05:10] <wgrant> What.
[05:12] <wgrant> It is almost unnoticably different :/
[05:13] <StevenK> Then how did you notice?
[05:13] <wgrant> "almost"
[05:19] <LPCIBot> Yippie, build fixed!
[05:19] <LPCIBot> Project devel build #571: FIXED in 5 hr 22 min: https://lpci.wedontsleep.org/job/devel/571/
[05:27] <StevenK> Uhhh, why is gina's doctest testing Python math?
[05:29] <lifeless> because twisted numpy accelerator for ssh changes global fnuctions
[05:32] <StevenK> That's so not related.
[05:32] <StevenK> lifeless: Can haz review?
[05:59] <StevenK> Methinks that means 'No'
[06:25] <lifeless> StevenK: check your mail
[06:26] <StevenK> lifeless: Thanks
[06:29] <poolie> do mps no longer show the diff inline in the page and only in the popup?
[06:30] <poolie> or is this just the problem that the diff is sometimes missing?
[06:34] <wgrant> The diff should always be there.
[06:38] <lifeless> poolie: mps don't have a popup; bug pages referencing mps have a popup
[06:39] <poolie> bug search timed out again
[06:40] <poolie> ok, i think it was just https://bugs.launchpad.net/launchpad/+bug/734629 then
[06:40] <_mup_> Bug #734629: empty/useless diff shown for merged proposals <code-review> <confusing-ui> <mail> <Launchpad itself:Triaged> < https://launchpad.net/bugs/734629 >
[07:24] <huwshimi> lifeless: I have a branch that adds an ajax time log. Here's a screen cap: http://people.canonical.com/~huwshimi/ajax_time_log.ogv
[07:24] <huwshimi> lifeless: I haven't figured out a way to add a useful identifier to that log yet though
[07:25] <huwshimi> lifeless: I'd like some suggestions about what other useful info you'd like to see there
[07:34] <lifeless> huwshimi: ----awesome----
[07:34] <lifeless> huwshimi: url
[07:34] <lifeless> huwshimi: and if it oopses the oops id
[07:41] <poolie> huwshimi, wow
[07:47] <huwshimi> lifeless: Yeah the url is the one I was trying to get before and couldn't. I can get back headers and data though so I should be able to oops info etc.
[07:47] <huwshimi> lifeless: I'll have a look again at the url
[07:47] <lifeless> perhaps we could stash the url in a response header
[07:50] <huwshimi> lifeless: well I'll try without that first, but it's good to know we can do that
[07:54] <stub> BinaryPackageReleaseDownloadCount is updated just over 8 times a second.
[07:55] <lifeless> 24M rows on qastaging.
[07:55] <lifeless> wow
[07:55] <stub> That is a batch job or live?
[07:56] <lifeless> batch I believe
[07:56] <stub> yer... I was wondering if you can translate that directly to downloads, but I don't think it does
[07:57] <StevenK> That's the job that parses librarian logs, I thought
[07:59] <stub> About a million downloads counted per day
[07:59] <lifeless> stub: hows the dbr looking - have we pushed the numbers down at all recently ?
[08:00] <stub> Which I think means every line counted results in an update. That could be much more efficient if we sacrificed a little RAM.
[08:03] <wgrant> stub: We batch the updates.
[08:03] <stub> lifeless: Roughly the same. Some wins - bug notification has dropped off from chewing ~17% of a core to <1%
[08:03] <wgrant> stub: At least it's meant to.
[08:04] <wgrant> We build up a massive dict.
[08:04] <stub> wgrant: But the same row might be updated multiple times in the run?
[08:05] <stub> wgrant: Or does the dict count everything, then the updates are made at the end?
[08:05] <wgrant> stub: It's possible, if the package has been copied.
[08:07] <stub> archivepublisher has dropped off the cpu chewing list too. Was it split into components, or just made awesome?
[08:07] <wgrant> stub: Just made a bit less awful.
[08:07] <lifeless> stub: when was it doing 17%?
[08:07] <LPCIBot> Project windmill build #97: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill/97/
[08:07] <wgrant> stub: Each BPRDC should be updated at most once in each batch.
[08:07] <stub> https://devpad.canonical.com/~lpqateam/dbr/weekly/db-report-2011-03-11-2011-03-18.txt from 2 months ago is what I'm using as a baseline
[08:07] <lifeless> stub: thats probably when we had the bad filter code
[08:08] <jtv> stub: what say you I lower statistics-logging in LoopTuner to DEBUG2?
[08:08] <stub> wgrant: Ok. That makes sense. If it becomes a problem, we could count everything first then do the updates in batches after the count is in.
[08:08] <lifeless> we're going to put the filters back in on monday
[08:08] <stub> jtv: I'm not fussed. If it makes things easier to work with, go for it.
[08:08] <wgrant> stub: We count everything first, but I guess Storm updates each row separately.
[08:08] <jtv> thanks stub
[08:09] <stub> wgrant: oic. It is just there are 1000000 rows to update :)
[08:09] <wgrant> stub: Heh, not quite that many, I hope.
[08:10] <lifeless> wgrant: batch update: insert into temp table (VALUES); select into ...
[08:11] <stub> Hmm... no... only 250k. So each tuple gets updated 4 times per day. Not sure 100% if that translates to 1 insert and 3 updates.
[08:11] <stub> Anyway... not anything to worry about atm....
[08:13] <stub> So 'less aweful' translates to a drop from 70% of a CPU core 2 months ago to no longer being on the list at all.
[08:14] <wgrant> stub: Huh, nice.
[08:15] <stub> appservers have dropped by 10% too, but that might not be statistically significant.
[08:15] <wgrant> stub: ew, distributionmirror shouldn't be that high.
[08:16] <stub> wgrant: no, and I think I have open bugs from me bitching about it in the past ;)
[08:16] <wgrant> stub: Where are you seeing the archivepublisher drop?
[08:16] <wgrant> It's still on yesterday's, at 70%...
[08:16] <bigjools> morning people
[08:16] <wgrant> Morning bigjools.
[08:17] <stub> Ahh crap.... please reverse everything I just said. The tabs where reversed :)
[08:17] <stub> So I guess the old lucille == archivepublisher and no change there
[08:17] <wgrant> stub: lucille turned into archivepublisher
[08:17] <wgrant> With no significant change.
[08:17] <wgrant> Right.
[08:18] <stub> And the appservers are chewing 10% more
[08:18] <stub> And bug notifications sucks dogs balls.
[08:18] <wgrant> Indeed, bugnotification is 40x what it was.
[08:18] <wgrant> Yellow!
[08:20] <lifeless> stub: this is worth a mail to the list +gary -> they want to add the mass filters to prod again; this high utilisation is a red flag for that
[08:20] <stub> k
[08:21] <jtv> wgrant: do we still need commercial-compat.sh?
[08:21] <wgrant> jtv: Yes, until Dapper dies in three months.
[08:22] <jtv> Three months, egad
[08:22] <bigjools> run-parts ...
[08:22] <jtv> hi bigjools.  wgrant: it's run at a somewhat awkward point in cron.publish-ftpmaster, and things would become a lot simpler if I could move it up or down just a bit.
[08:23] <jtv> So I was wondering: does it have to be run after the new dist directories are moved into place?
[08:23] <jtv> Or alternatively, does it have to be run before the ls-lR.gz files are generated?
[08:24] <wgrant> It should be able to run after ls-lR, I think.
[08:24] <jtv> bigjools: seeing 4 streaks of runparts invocations at the moment, 3 of which run twice.  Looking at how that number might be reduced.
[08:24] <wgrant> Let me check.
[08:24] <wgrant> runparts?
[08:24] <bigjools> jtv: hmmm we can surely consolidate some
[08:24] <jtv> I should hope so
[08:25] <bigjools> I thought there should only be 2
[08:25] <bigjools> remember that run-parts orders stuff if you want
[08:25] <jtv> wgrant: I'm rewriting cron.publish-ftpmaster in python, and the plan is to "outsource" a lot of the work to run-parts directories.
[08:25] <wgrant> jtv: Ah.
[08:25] <jtv> bigjools: yes, but there's stuff inbetween that doesn't look like it belongs in run-parts.
[08:25] <bigjools> it's more like adding hooks for non-generic stuff to live in
[08:25] <jtv> Such as moving the dists directory into place: can we move that into run-parts?
[08:26] <bigjools> no, that's generic
[08:26] <bigjools> but we might be able to move things around
[08:26] <wgrant> jtv: So, commercial-compat has to run before ls-lR, and after dists
[08:26] <wgrant> jtv: Unless you make it work on dists.new instead.
[08:26] <jtv> :/
[08:26] <jtv> oh
[08:27] <wgrant> Or delete partner
[08:27] <bigjools> it's odd that nobody has had errors about incomplete PPA dists
[08:27] <bigjools> since we don't do them atomically
[08:27] <wgrant> bigjools: buildds do occasionally.
[08:27] <wgrant> But they update infrequently and quickly.
[08:27] <bigjools> ah interesting
[08:28] <bigjools> on another note, isn't it a royal pita to see your ec2 land succeed and then pqm is in testfix!
[08:28] <wgrant> Yes, someone left it in testfix overnight :(
[08:28] <bigjools> :/
[08:29] <wgrant> It failed like half an hour after I last checked it, and was failed when I started this morning...
[08:29] <wgrant> Which makes me rather sad.
[08:30] <bigjools> StevenK: hello
[08:30] <jtv> bigjools, wgrant: right now the basic structure looks like http://paste.ubuntu.com/584690/
[08:31] <wgrant> jtv: You will ideally be able to move signReleases into publishDistro (for PPAs it's already there)
[08:31] <jtv> 4 stretches of "runparts" code, which is a bit much.  The smallest change I see that would help with that is to move installDists() down one step.
[08:31] <wgrant> We can also hopefully get rid of copyIndices, because it's stupid.
[08:31] <wgrant> What's installDists?
[08:31] <jtv> Moving signReleases into publishDistro doesn't help.
[08:31] <bigjools> why is 4 too much?
[08:31] <jtv> wgrant: installDists moves the dists directories into place.
[08:32] <wgrant> jtv: So, installDists and removeUncompressedListings and signReleases all go into publishDistro.
[08:32] <jtv> bigjools: there's no such thing as "too" much, but maintenance is going to be easier when it's fewer.
[08:32] <bigjools> why?
[08:33] <jtv> Because it's hard to explain exactly what each of those 4 run-parts directories is going to be fore.
[08:33] <bigjools> so naming stuff is hard? :)
[08:33] <wgrant> jtv: I think there's only one run-parts.
[08:33] <jtv> wgrant: what about copyIndices?
[08:33] <wgrant> Post-publication stuff.
[08:34] <wgrant> jtv: Does that put stuff in dists?
[08:34] <jtv> Err
[08:34] <jtv> …
[08:35] <wgrant> That would be a no.
[08:35] <jtv> if [ "$LPCONFIG" = "$PRODUCTION_CONFIG" ]; then
[08:35] <jtv>     echo "$(date -R): Copying the indices into place."
[08:35] <jtv>     rm -f $INDICES/override.*
[08:35] <jtv>     cp $OVERRIDEROOT/override.* $INDICES
[08:35] <jtv> fi
[08:35] <wgrant> So it doesn't have to run before installdists.
[08:35] <jtv> is what it does.
[08:35] <wgrant> So we have this:
[08:35] <wgrant> publishDistro
[08:35] <wgrant> run-parts
[08:35] <wgrant> The end.
[08:36] <wgrant> "if not self.options.security" is implemented by the Python script calling run-parts with an env-var which tells them whether it's a security run or not.
[08:36] <jtv> Well, it's not quite that simple of course because we need to do most of this twice per script run.
[08:36] <wgrant> Long-running scripts can avoid running if the security flag is set.
[08:37] <wgrant> We could also pretend that the concept of a security run doesn't exist.
[08:37] <wgrant> jtv: Why must we do it twice?
[08:37] <jtv> To expedite security uploads.
[08:38] <wgrant> Is that actually used?
[08:38] <jtv> You're in a better position to answer that than I am.  But it's in the original script and it's in the design for its replacement.
[08:39] <jtv> So you could say it's already automatically used, but we don't know whether we rely on it in any way.
[08:39] <wgrant> Keep in mind that this script was written in 2005. Most of the assumptions it makes can probably be brought into question.
[08:39] <wgrant> eg. dsync kill it with fire.
[08:39] <jtv> That's exactly what I'm doing here: questioning the assumptions.
[08:39] <jtv> dsync goes into run-parts where it's not my problem.
[08:39] <wgrant> True.
[08:40] <jtv> Signing of releases is something I'd like to divest myself off as well though.
[08:40] <wgrant> Why?
[08:40] <wgrant> We already have the code to do that.
[08:40] <wgrant> But the primary archive doesn't use it.
[08:41] <bigjools> I don't want jtv's job complicated with that right now
[08:41] <jtv> We already have the code to divest ourselves of it?  Or we already ahve the code to sign releases?
[08:41] <wgrant> jtv: The signing code.
[08:41] <wgrant> PPAs.
[08:41] <bigjools> by all means file a bug and do it, but not in this change
[08:42] <jtv> I also imagine there's the variable of what GPG key is to be used.
[08:42] <wgrant> I think we should be fixing publish-distro before we try to make its wrapper sensible...
[08:42] <bigjools> I disagree
[08:42] <wgrant> The wrapper can be a lot more sensible if it doesn't duplicate functionality that's already in publish-distro.
[08:42] <jtv> What I'm doing is at least bringing out the structure in what the old script does, and allows us to re-think these assumptions.
[08:43] <lifeless> bigjools: btw - we got the go ahead to combine the soyuz (s)ftp services and uploader into one
[08:43] <jtv> Also, at least now we can run tests.  In temporary directories.  Without global setup and writing to /srv/launchpad.net.
[08:44] <bigjools> lifeless: I am fearful but ok
[08:44] <lifeless> bigjools: we can always split it into two again - or optimise
[08:44] <bigjools> lifeless: this will break the "you get an email in a few minutes" thing more often
[08:44] <lifeless> but it will be a simpler initial config, which is important at the moment
[08:45] <bigjools> lifeless: did you ask anyone why they were split like that in the first place?
[08:45] <lifeless> bigjools: you asked elmo, I didn't see a reply from him
[08:45] <bigjools> that's a no then? :)
[08:45] <lifeless> bigjools: if he doesn't know, I suspect noone is left that knows ;)
[08:47] <lifeless> bigjools: we can dig further - I've no objection to more info
[08:47] <bigjools> lifeless: I think it would be wise
[08:47] <lifeless> bigjools: the main point for me is that we have the stakeholder buy in to do whatever tradeoff make the most sense for now
[08:47] <bigjools> just from being burned in the past by seemingly innocuous changes like this
[08:48] <lifeless> bigjools: this one seems pretty big to me :) - if we do it it would be staged, easily reversible etc
[08:48] <bigjools> lifeless: did we get a reply from platform?
[08:48] <lifeless> bigjools: silence (neither a 'whaaa' nor anything specific)
[08:48] <bigjools> I think a direct question would be good then
[08:48] <lifeless> bigjools: marjo I think, said to me that the mail was forwarded to platform directly
[08:49] <bigjools> they may not have seen it
[08:51] <lifeless> bigjools: he cc'd me; I think they have seen it - he pulled out the TL;DR summary for us
[08:52] <bigjools> what is this tl;dr fad
[08:52] <lifeless> bigjools: I'll check with elmo and flacoste and so on when we've finished the single-threaded stack
[08:52] <lifeless> bigjools: too long didn't read?
[08:52] <bigjools> yes I know what it means :)
[08:53] <lifeless> :P
[08:53] <bigjools> lifeless: anyway, go ahead with the change, I've raised any concerns I may have
[08:53] <adeuring> good morning
[08:54] <lifeless> bigjools: I'll drag you into it when we get up to making the uploaders HA during deploys - i don't think any decision needs to be made yet.
[08:54] <lifeless> bigjools: I'm just happy we have a broad set of options
[08:54] <bigjools> lifeless: indeed!
[08:54] <jtv> wgrant: what does dsync-flist do exactly?
[08:54] <bigjools> options are good
[08:54] <bigjools> that's why I run KDE
[08:54] <wgrant> jtv: hardlinks common files.
[08:55] <wgrant> jtv: It saves roughly a megabyte, I believe.
[08:55] <bigjools> ha
[08:55] <jtv> wgrant: sorry just to be clear, that's a megabyte of L2 CPU cache right?  ;-)
[08:55] <wgrant> Heh
[08:56] <jtv> So… could I just simply kill it, drop it from the script, do away with it, no questions asked?
[08:57] <bigjools> I doubt anyone would notice it missing
[08:57] <jtv> Gone.
[08:58] <jtv> Don't security uploads need to germinate?
[08:58] <bigjools> no
[08:59] <jtv> (And by the way, triggering mirrors looks like a prime candidate for "&" in the run-parts script)
[09:00] <jtv> Germination is not generic to all distros, right?
[09:00] <wgrant> Most will probably want it. But they should run the script themselves, since it's fairly specific, and I wish it would get out of our tree.
[09:00] <bigjools> jtv: mirror trigger is very quick
[09:01] <bigjools> germination is distro-specific
[09:01] <bigjools> that script is not really owned by LP even though it's in our tree
[09:01] <jtv> Oh, ISTR back in 2006 we tried to run some of this stuff on a non-Canonical machine and it just froze up trying to connect to each mirror.
[09:01] <jtv> So I sort of remembered it as being slow.
[09:05] <jtv> bigjools: what was your verdict on signing?  run-parts or generic?
[09:06] <bigjools> jtv: run-parts for now since it's less work and won't mess up this change.
[09:06] <jtv> Well I'm not 100% sure it's less work.  I see 2 options:
[09:07] <jtv> 1. Do this in run-parts, and have another script in the same dir that finds and removes the uncompressed Sources/Packages files.
[09:08] <jtv> 2. Implement it in the script itself, and have one run-parts directory less.  (The removing of uncompressed files could also go into the script, or into the next run-parts stretch)
[09:09] <wgrant> bigjools: Oh yeah, it turns out that delayed copies are now much slower than direct copies.
[09:09] <bigjools> wgrant: !
[09:09] <bigjools> "delayed" would imply that :)
[09:09] <wgrant> Since delayed copies still scale by number of BPRs.
[09:09] <wgrant> Heh
[09:10] <bigjools> so if you can guarantee that the security team can unembargo a kernel using a direct copy, please remove delayed copies
[09:10] <bigjools> we can get rid of that re-upload crap too
[09:10] <wgrant> Can't yet. Need to move notifications and overrides into direct copies :(
[09:10] <wgrant> And that, yes.
[09:10] <bigjools> we can get rid of that anyway
[09:10] <wgrant> I'm going to see if doing constant-query overrides is easy.
[09:10] <wgrant> If so, I'll JFDI.
[09:10] <bigjools> hooah
[09:11] <mrevell> Hey
[09:13] <jtv> hey!
[09:18] <wgrant> bigjools: I guess this will also have the convenient effect of stopping copy-package from breaking the archive.
[09:18] <poolie> hi all
[09:20] <henninge> Hi adeuring!
[09:21] <henninge> adeuring: your soyuz translations upload branch landed! Good job on finding the right spot. ;-)
[09:26] <adeuring> henninge: thanks :)
[09:26] <henninge> adeuring: Unfortunately it seems to be doing a little too much ... :(
[09:26] <adeuring> henninge: really?
[09:26] <henninge> adeuring: we still need the *templates* to be uploaded
[09:26] <adeuring> henninge: ah, right
[09:27] <henninge> adeuring: so addOrUpdateEntriesFromTarball needs to filter only for pot files.
[09:27] <adeuring> henninge: right
[09:27] <henninge> actually, there is a function that checks that
[09:27] <henninge> I was just looking for that
[09:29] <henninge> adeuring: TranslationImporter.isTemplateName
[09:31] <henninge> adeuring: you should be able to add a flag 'only_templates' to addOrUpdateEntriesFromTarball and use that in _isTranslationFile.
[09:31] <adeuring> henninge: right
[09:31] <henninge> adeuring: I am sorry but this really needs to be done before this gets rolled out. Let me file a bug for it.
[09:37] <poolie> jml, hi?
[09:40] <henninge> adeuring: bug 741571
[09:40] <_mup_> Bug #741571: Translation templates should always be uploaded from soyuz builds. <regression> <upstream-translations-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/741571 >
[09:44] <bigjools> wgrant: sorry was otp, to which breakage are you referring, for there are many :)
[09:44] <wgrant> bigjools: The "oh, you wanted to copy a universe package from a PPA? let me just silently promote that for you" one, mainly.
[09:45] <bigjools> ah
[09:53] <henninge> adeuring: I touched that code, too, because I have removed the translationsharinginfo module. But that branch is just landing.
[09:54] <adeuring> ok
[09:54] <henninge> adeuring: are you busy now or should I fix that?
[09:54] <adeuring> henninge: let's dice ;)
[09:55] <henninge> adeuring: I roll a W20 ...
[09:55] <henninge> ...
[09:55] <henninge> 20!
[09:55] <henninge> adeuring: I win ;)
[09:55] <adeuring> henninge: 20*19*18... is a huge number
[09:55] <henninge> :(
[09:55] <henninge> oh
[09:55] <adeuring> henninge: ok, so you'll fix the bug?
[09:56] <henninge> adeuring: yeah, I just thought of some other optimization for my last branch that I could include.
[09:56] <adeuring> henninge: cool, thanks
[10:01] <dpm> hi jml, did you have the chance to have a look at signing up for a session on Launchpad for Ubuntu AppDeveloperWeek or finding someone else to run it?
[10:27] <wgrant> bigjools: Your sync button is buggy.
[10:27] <bigjools> ffs
[10:28] <wgrant> bigjools: syncSources copies the latest published source in the archive, which could be, say, a security upload.
[10:28] <wgrant> It does not discriminate by series or pocket.
[10:29] <wgrant> :D
[10:30] <bigjools> I expected I'd need to fix it later to sync the versions specified
[10:32] <jtv> Any reviewers available?  https://code.launchpad.net/~jtv/launchpad/bug-741585/+merge/54674
[10:33] <bigjools> wgrant is like the eye of Sauron
[10:33]  * jtv tries to see a way that comparison works
[10:33] <jtv> —but fails
[10:33] <wgrant> bigjools: Sadly not.
[10:34] <bigjools> I have a vision of an eye sweeping the Launchpad landscape looking for bugs
[10:35] <jtv> bigjools, you've been reading too much of that "LotR from Sauron's perspective" stuff
[10:36] <bigjools> or maybe I feel like Frodo trying to sneak bugs past the eye :)
[10:38] <wgrant> One does not simply land hacks into Mordor.
[10:39] <wgrant> StevenK: Do you have a solution to your version issue? I see two possibilities.
[10:46] <jtv> bigjools, another Q about publish-ftpmaster: we only need to call process-accepted once, despite the "run once for security, run once for everything" structure, right?
[10:47] <jtv> stub, care to review my little logging cleanup?  https://bugs.launchpad.net/launchpad/+bug/741585
[10:47] <_mup_> Bug #741585: FakeLogger doesn't quite conform to logging API <Launchpad itself:In Progress by jtv> < https://launchpad.net/bugs/741585 >
[10:48] <wgrant> :(
[11:02] <jtv1> bigjools: if we won't be needing commercial-compat.sh for much longer, maybe I should just hard-code it in and we can drop it from the script later.  It actually makes things simpler.
[11:02] <jtv1> (In the long run, that is)
[11:03] <jtv> I can just add an "if we're doing ubuntu" guard around it, and add an XXX.
[11:04] <deryck> Morning, all.
[11:04] <stub> jtv: k
[11:04] <jtv> thanks
[11:04] <jtv> hi deryck
[11:07] <stub> jtv: I thought I fixed it so our custom logger class is registered so we shouldn't see any 'standard' loggers?
[11:08] <jtv> stub: but by "our custom logger class" you don't mean the FakeLogger, do you?
[11:08] <jtv> Oh, I see what you mean
[11:08] <jtv> you mean I could just call debug2.
[11:08] <stub> That should work, yes.
[11:08] <jtv> If that's safe, then I'll do it that way.
[11:08] <wgrant> eeeeeep
[11:09] <stub> If it doesn't work, there is a bug somewhere (retrieving a logger through some weird mechanism?), but that could wait for another branch
[11:09] <jtv> stub: I take it that debug2 will call self.log(DEBUG2, *x, **y)
[11:09] <stub> Yes
[11:09] <jtv> I didn't run into a problem with that; I was just being conservative.
[11:10] <jtv> Running tests.
[11:10] <stub> Actually, according to lp/services/log/loglevels.py it is _log for reasons I don't recall but might be documented in the python reference
[11:11] <stub> Or maybe it was the sourcecode...
[11:11] <stub> Its registered with the logging module in lp_sitecustomize.py anyway
[11:12] <jtv> stub: AttributeError: RootLogger instance has no attribute 'debug2'
[11:13] <stub> With the normal logger or your FakeLogger with debug2() added?
[11:13] <jtv> Probably the normal logger.
[11:13] <jtv> I don't think my FakeLogger has debug2 though.
[11:14] <jtv> There's nothing overriding the logger in that test.
[11:14] <stub> You might need to add it, or make it inherit from LaunchpadLogger instead of the logging module class.
[11:14] <jtv> Or call log() and have it just work.  :)
[11:15] <stub> I fixed this so I didn't have to keep seeing log(DEBUGX, 'foo') everywhere ;)
[11:15] <jtv> Also, I don't _think_ the FakeLogger has a debug2 method but I'm not sure
[11:16] <stub> Yes, you will need to add debug2 to FakeLogger if it isn't there. If it isn't there, it is broken as it isn't a complete mock of the real thing.
[11:16] <jtv> I could fix this up, but that would start to look like a rabbit hole and I'd prefer to be unblocked on my main job (which is a scary soyuz script overhaul)
[11:18] <stub> You have a branch that mainly consists of making things less readable, when adding a three line method on FakeLogger would keep the readability and fix a bug.
[11:20] <stub> Well.. not mainly. You have only changed two .debug2 callsites to use the old syntax.
[11:22] <jtv> But the problem I just ran into is not the FakeLogger.  So fixing up the FakeLogger wouldn't fix that one; there is yet another bug to fix.
[11:25] <stub> ok
[11:25] <jtv> The logger I seem to be getting (and which doesn't seem to have debug2) is canonical.launchpad.scripts.log.
[11:25] <stub> jtv: In what cases do you find you have None as a level?
[11:26] <jtv> I'm not aware of any.  Not sure that deserves to be in there.
[11:26] <stub> ok. Add a comment there mentioning that, or remove it.
[11:27] <jtv> I'll remove it.  It's a bit of legacy crud from jml's merging of fake loggers.
[11:27] <jtv> At least one of the old fake loggers printed "log>" instead of a log level.
[11:29] <stub> jtv: So it looks like lp_sitecustomize.py installs the custom class, and instances are correctly returned for new loggers but the root logger isn't updated.
[11:29] <jtv> I have no idea what you just said.
[11:29] <stub> (testing with 'make harness')
[11:30] <stub> The registration of our custom logger class works for everything except the root logger, which is bogus.
[11:30] <jtv> Sounds like it… what can we do about it?
[11:30] <stub> Surprised this hasn't fallen over before.
[11:30] <stub> I'll have a quick poke to see if it is an easy fix, or open a bug which you can cite in your branch.
[11:31] <jtv> Thanks.
[11:32] <jtv> I've added the new log levels.
[11:35] <bigjools> jtv: sorry just saw your questions
[11:36] <jtv> tsk
[11:36] <bigjools> jtv: p-a only needs to run once
[11:36] <jtv> Running it from the script does introduce the PATH question again, of coursee.
[11:36] <jtv> Oh, different question :)
[11:36] <jtv> Thanks.
[11:36] <bigjools> jtv: embedding commercial compat is ok
[11:37] <bigjools> but file a bug of course :)
[11:37] <jtv> Naturally.
[11:37] <jtv> That brings us down to 2 run-parts dirs: after publish-distro and at the very end.
[11:38] <bigjools> rock on
[11:38] <jtv> For the latter, the scripts will be told in some way whether this is a security-only expedited publishing or a proper full one.
[11:38] <bigjools> so post-publication.d and pre-exit.d ?
[11:38] <jtv> I still need to check whether all of the parts break down neatly into archives.
[11:38] <jtv> Something like that, I guess.
[11:40] <jtv> bigjools: what about the renaming of dists to dists.new?  That looks like it needn't be repeated either.
[11:41] <jtv> I should say: renaming of dists to dists.new plus subsequent rsync from distsroot.
[11:41] <bigjools> mmmm
[11:41] <bigjools> not sure
[11:45] <stub> jtv: So https://pastebin.canonical.com/45170/ looks like the fix, and works with bin/harness. Want to dig the rabbit hole a little deeper and save me making a separate branch?
[11:46]  * jtv waits for that page to load…
[11:48]  * jtv waits for openid…
[11:49] <jtv> ah, there's my page!
[11:51] <jtv> stub: I realize this is piling work onto you, which pains me, but I'd really rather not risk the potential Q/A fallout while I'm doing soyuz feature work.
[11:51]  * stub opens a bug
[11:52]  * jtv gets ready to xxx the bug number
[11:54] <stub> Bug #741650
[11:54] <_mup_> Bug #741650: root logger is not a LaunchpadLogger <Launchpad itself:Triaged> < https://launchpad.net/bugs/741650 >
[11:58] <jml> jtv: thumper's merging
[11:58] <stub> jtv: Copywrite in logger.py should be 2010-2011, not 2011
[11:58] <jtv> my apologies
[11:59] <jtv> stub: fixing
[12:00] <henninge> adeuring: I am done. Want to review?
[12:00] <henninge> adeuring: https://code.launchpad.net/~henninge/launchpad/devel-741571-filter-templates-in-upload/+merge/54688
[12:00] <adeuring> henninge: sure
[12:01] <henninge> adeuring: I'll be out to lunch now, you can ask questions later.
[12:01] <adeuring> ok
[12:01] <henninge> adeuring: but I think this is a pretty clear branch, I really enjoyed coding this.
[12:01] <stub> jtv: Thats it. r=stub.
[12:01] <jtv> stub: thanks—changes pushed, on the way to EC2.
[12:02] <stub> jtv: For lint issues like the one you mentioned, I usually go with whatever makes lint shutup.
[12:03] <jtv> stub: me too, usually.  This is the one exception.  I won't add warnings like that, but I'm hesitant to clean them up.
[12:13] <stub> jtv: What test are you using for this? I want to test my branch
[12:14] <gary_poster> stub, thanks for heads up.  Remind me where the db utilization report is, please?  I'd probably like to talk to you about your concerns too, once I've gotten more familiar with the data.
[12:14] <jtv> stub: I simply replaced the log calls in looptuner.py with debug2 calls and then ran looptuner.txt.
[12:14] <stub> gary_poster: https://devpad.canonical.com/~lpqateam/dbr/
[12:14] <gary_poster> thanks
[12:14] <stub> jtv: ta
[12:16] <stub> gary_poster: Its not causing problems yet, but it certainly should be looked into since it is a big jump and affects our scalability. Robert asked me to raise it because of the work I believe you are doing.
[12:19] <gary_poster> stub, right.  We are doing more work now on the asynchronous side.  It is doing features that have been requested, of course.  Do you have any concrete suggestions on next steps?  The only thing I know of is to try to take a glance at the pertinent code and see if it can be simplified, but that seems fairly vague.
[12:21] <stub> gary_poster: If we know what extra work it has started doing in the last two months, then we can tell if the extra load is justified or not. I don't know what it is doing - I just see the percentage.
[12:23] <stub> gary_poster: I think Robert's main concern is that we are currently in a performance drive, and shouldn't be landing code that makes performance worse (which it seems we have)
[12:23] <jtv> bigjools: do we copy overrides only for the main archive?
[12:23] <gary_poster> stub, even asynchronously, for requested features?  How do we know that this is a problem?
[12:23] <bigjools> jtv: copy?
[12:23] <gary_poster> Amusingly to me, two months ago would be about the week when we started working on this, of course. :-)
[12:23] <jtv> bigjools:     cp $OVERRIDEROOT/override.* $INDICES
[12:24] <jtv> $INDICES is in the main archiveroot
[12:24] <bigjools> jtv: overrides only apply to main archives
[12:24] <jtv> Perfect.  Thanks.
[12:24] <bigjools> so far anyway :)
[12:24] <gary_poster> ah it's less than 2 mo though...
[12:24] <jtv> Well, not perfect, but then I know what to implement.  :)
[12:25] <stub> gary_poster: You would have to discuss features vs. performance drive with lifeless :-) I don't think it is affecting production performance yet, but it has lessened our scalability somewhat.
[12:25] <gary_poster> ack stub.  ok thanks.
[12:26] <stub> gary_poster: It might just be we are missing an index or similar if we can work out what has changed and what we are doing differently now. Or maybe we just have to put up with it, because the extra work is required for some reason.
[12:27] <stub> gary_poster: The two months figure I got because today I compared this weeks report with a report from two months ago. It could have spiked any time between then and now.
[12:27] <gary_poster> understood stub.  I have a suspicion I know the cause, and will investigate and report back on the list.  Thanks again for the heads up.  It started rising in early March.  https://devpad.canonical.com/~lpqateam/dbr/weekly/db-report-2011-03-04-2011-03-11.txt
[12:28] <stub> (In fact, first of all I erroneously compared them in reverse and was singing the praises of whoever stopped bugnotifications from chewing on the cpu :) )
[12:28] <gary_poster> lol
[12:43] <stub> jtv: https://code.launchpad.net/~stub/launchpad/trivial/+merge/54692 (to try landing tomorrow after your branch)
[12:43] <jtv> stub: I know, I'm already looking
[12:44] <jtv> stub: does lp_sitecustomize get run by scripts as well?
[12:44] <jtv> Not sure it matters,
[12:44] <jtv> since we seem to have some logging magic for scripts anyway that probably already sets things right there
[12:45] <stub> jtv: Its buildout magic. Everything in our tree gets it
[12:45] <stub> (unless you forget python -S or _pythonpath)
[12:46] <jtv> stub: approved
[12:47] <stub> ta. I guess I can punt it to ec2 land to see what explodes now - if your branch fails, this one will fail too since I merged yours in.
[12:48] <jtv> stub: looks like my instance never fully set up, but since my review is also approved, "ec2 land" should just land them both.
[12:48] <jtv> (Unless it doesn't want to do that across users)
[12:48] <stub> jtv: Actually, I'll wait. Better two separate landings in case mine needs to be backed out.
[12:48] <jtv> OK
[12:48] <jtv> I should get a chance to send it in tonight.
[12:51] <jml> Can I get a review of this please: https://code.launchpad.net/~jml/launchpad/test-timeout-505913/+merge/54598
[13:06] <abentley> deryck: chat?
[13:07] <deryck> abentley: sure.
[13:07] <deryck> abentley: let me head to the mumbler
[13:18] <jml> 'ec2 test' is complaining about me not having an SSH agent running.   If you look at lp:~jtv/launchpad/bug-55798 at the last dozen lines of lib/lp/soyuz/scripts/publish_ftpmaster.py you'll see the structure I have now, which is thankfully shaping up to be pretty simple.
[13:19] <jml> maybe I need to set an env var or something
[13:20] <jml> huh. my keys weren't in it. odd.
[13:20] <wgrant> jml: Natty?
[13:20] <jml> wgrant: indeedly
[13:21] <wgrant> jml: Unity been crashing?
[13:21] <jml> wgrant: Does a bear... well, you know the rest.
[13:21] <wgrant> It sometimes doesn't restore the environment properly.
[13:21] <jml> wgrant: ok.
[13:22] <jml> anyway, running ssh-add makes everything better. just going to test my branch that fixes the intermittent test_timeout failure
[13:22] <jml> maybe it'll be done by the time it gets reviewed.
[13:23] <leonardr> abentley: if you can take another look at https://code.launchpad.net/~leonardr/launchpad/explicit-versions/+merge/54558, i can get it into ec2 land
[13:28] <leonardr> wallyworld, you run tests with bin/test
[13:31] <abentley> leonardr: looking
[13:33] <abentley> leonardr: r=me
[13:55] <gmb> jcsackett: Can I get a review of https://code.launchpad.net/~gmb/launchpad/fix-fragile-link-bug-741645/+merge/54698 please? Only 20 lines.
[13:55] <jcsackett> gmb: sure thing.
[13:55] <gmb> Ta
[13:59] <jml> abentley: could you please review https://code.launchpad.net/~jml/launchpad/test-timeout-505913/+merge/54598
[13:59] <abentley> jml: sure, but I've got a standup first.
[13:59] <jcsackett> gmb: r=me.
[13:59] <gmb> Thanks jcsackett
[13:59] <jml> abentley: thanks.
[14:06] <jml> why am I allowed to change translations settings for empathy (upstream) on lpnet but not qastaging?
[14:06] <jml> (https://translations.launchpad.net/empathy vs https://translations.qastaging.launchpad.net/empathy)
[14:15] <bigjools> jml, wgrant: I have to ssh-add every session because the stupid script assumes I'm running Gnome desktop
[14:15] <jml> bigjools: "stupid script" == utilities/ec2?
[14:16] <bigjools> jml: I'm not sure which part exactly, something to do with one of the included modules I expect
[14:16] <bigjools> keyring wants to use the gnome agent as well, instead of the kwallet
[14:17] <jml> I'm guessing this isn't https://bugs.launchpad.net/launchpad/+bug/577118
[14:17] <_mup_> Bug #577118: ec2test barfs if the ssh-agent keys are stored in the wrong order <build-infrastructure> <ec2test> <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/577118 >
[14:19] <bigjools> don't think so
[14:19] <benji> bigjools: I've added a section to https://dev.launchpad.net/LandingChanges that has instructions for telling keyring to use unencrypted flat files for credential storage so you don't have to type in passwords or fiddle with keyrings
[14:19] <bigjools> benji: yep, I saw that thanks.  I don't mind that so much as the problem with the ssh keys
[14:20] <sinzui> jcsackett: ping
[14:20] <jcsackett> sinzui: good morning.
[14:20] <sinzui> jcsackett: do you have time to talk about a branch I am starting: http://pastebin.ubuntu.com/584441/
[14:22] <jcsackett> sinzui: sure.
[14:22]  * jcsackett starts mumble
[14:29] <bigjools> deryck: so, looking at Selenium yet? :)
[14:31] <deryck> bigjools: I would be interested in Selenium, definetly. :-)
[14:31] <bigjools> :)
[14:32] <bigjools> it was in reference to your last tweet/fb
[14:32] <deryck> bigjools: other parts of Canonical are using it now.  Windmill is all but dead, except for us
[14:32] <deryck> bigjools: right :-)
[14:32] <bigjools> yeah, it's not developed any more even, I heard?
[14:32] <deryck> right, it's pretty dead, I think
[14:32] <deryck> I just don't have an easy path off of Windmill
[14:32] <bigjools> except we have a twitching limb
[14:33] <deryck> heh
[14:33] <bigjools> I'll see if my team can help with this when we get to the feature review stage
[14:33] <deryck> bigjools: oh, dude!  That would be wonderful.
[14:34] <bigjools> don't get too excited, it's a month away or so :)
[14:34] <deryck> heh, fair enough :-)
[14:34] <bigjools> when we discussed it we were all of the opinion that we should not flog the dead
[14:36] <deryck> I think the important thing is to get it added as an option for these sort of tests and then get an example test going.
[14:36] <deryck> and not make the same mistakes again :-)
[14:36] <deryck> e.g. maybe we should consider running them separtely from our normal tests, decoupled from the Zope test runner
[14:38] <deryck> they have to block in some way to be useful, but exactly what that blocking mechanism is good be looked at, too.
[14:38] <bigjools> I'd be willing to do that
[14:38] <deryck> s/good/could/ (for my last one)
[14:38] <bigjools> we need to look at how many of our landed branches would need that sort of test
[14:38] <deryck> yes
[14:38] <bigjools> worth an experiment!
[14:39] <deryck> very much so!
[14:39] <deryck> selenium would, I think, allow us to have real web page integration tests that were more stable, rather than the minimal XHR integration test I'm preaching for now
[14:39] <bigjools> unfortunately I know next to bugger all about the whole JS environment so I can't be very helpful right now.  I aim to delve into this in more detail soon though.
[14:40] <deryck> I'm just thrilled to have someone express an interest :-)
[14:40] <bigjools> ha :)
[14:43] <abentley> jml: what's _logTimeout for?
[14:45] <bigjools> james_w: it struck me that there's nothing in the derived distros LEP about considering pockets when working out package differences.  Right now it'll just grab whatever was most recently published but I'm not sure if that will always be what's required.  Any thoughts?
[14:45] <james_w> bigjools, could you expand please?
[14:46] <bigjools> james_w: ok for example say the most recent upload is to -backports.  It'll show up as a diff but won't say it's from -backports.
[14:46] <bigjools> you may not want to sync from backports :)
[14:46] <james_w> hmm, indeed
[14:47] <bigjools> so I'm trying to flesh out the use cases here so we can work out what to change to make this work better
[14:47] <james_w> my initial guess is that you would want an item for each pocket that had a new version published
[14:48] <bigjools> that's what I thought - you'd end up with multiple rows for the same package showing in the table of diffs
[14:48] <james_w> "-security has <this> and -updates has <that>" and you can choose which to sync
[14:48] <bigjools> yup
[14:48] <james_w> if you chose the later one then the other would go away
[14:49] <bigjools> interesting
[14:49] <abentley> jml: it seems test_timeout_short has a lot in common with test_timeout.  Could we extract the common code to a helper?
[14:49] <james_w> it's not quite right, but I don't see a better way
[14:52] <abentley> jml: IIRC, raising an exception meant that the oops would contain a traceback showing what code had timed out.  It seems a shame to lose that.
[14:56] <bigjools> james_w: I'll ask a few more people and get some consensus
[14:56] <james_w> ok
[14:56] <bigjools> cheers
[15:32] <bac> gary_poster, jcsackett: either of you going to trizpug tonight?
[15:33] <jcsackett> bac: i'm not sure. there's a decent chance of 'no'.
[15:33] <gary_poster> no. previous commitment, bac (to painting a mural in the baby's room)
[15:33] <bac> jcsackett: that's my inclination too
[15:34] <jcsackett> bac: in my case, i need to contact one of the other splatspace members. he's technically the point man for the meeting, but is not always on time, and someone has to be there to open doors.
[15:35] <bac> jcsackett, gary_poster: on an unrelated note, andrea from lanter is a james beard finalist.
[15:35] <bac> lantern
[15:35] <jcsackett> cool.
[15:35] <gary_poster> cool :-)
[15:48] <benji> Does allhands eat newlines in objective "Progress Notes" for anyone else.  It really hurts the readability of my text.
[16:55] <jcsackett> bac: confirmed, i won't be there tonight.
[16:59]  * jcsackett is having a braindead day.
[17:00] <adeuring1> abentley: my branch lp:~adeuring/launchpad/js-translation now also shows the corect "add packaging" icon
[17:03] <bigjools> you can't beat a good refactoring for satisfaction
[17:03] <jml> abentley: have you had a chance to look at that branch?
[17:33] <LPCIBot> Project windmill build #98: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill/98/
[17:49] <bigjools> jml: too late
[17:50] <bigjools> I already submitted a fix
[17:50] <abentley> jml: I did, and I asked you some questions about it.
[17:50] <jml> bigjools: oops. missed your mail (Gmail put it into a different thread :()
[17:51] <bigjools> jml: awesome Gmail :)
[17:51] <bigjools> jml: except PQM just blew me out, grar
[17:51] <jml> abentley: on the channel?
[17:52] <jml> ahh yes.
[17:52] <jml> abentley: logTimeout is for making sure the logged oops is a TimeoutError, not ProcessDone(42)
[17:53] <jml> abentley: the tests are fairly short. I guess I could put the logger stuff in setUp and make a custom assertion. Not sure whether that would be better.
[17:54] <jml> abentley: re <abentley> jml: IIRC, raising an exception meant that the oops would contain a traceback showing what code had timed out.  It seems a shame to lose that.
[17:55] <jml> abentley: I agree, it is a shame. I'm not sure we can do that and avoid the race.
[17:56]  * jml tries something
[17:56] <jml> (although I don't really know how to verify the traceback
[17:56] <jml> )
[17:56] <abentley> jml: would it be crazy to log the oops in a signal handler?
[17:57] <jml> abentley: I don't *think* so. The caveats about complexity that we discussed the other day would apply.
[17:58] <jml> abentley: I was thinking of try: raise TimeoutError; finally: os._exit(TIMEOUT_CODE), or something similar.
[17:58] <abentley> jml: I don't understand how that would result in a traceback in the oops.
[18:00] <bigjools> right, time to make like a shepherd.  Good night all.
[18:00] <jml> abentley: well, probably something more like finally: reactor.callLater(0, os._exit(TIMEOUT_CODE))
[18:00] <abentley> jml: Ah.
[18:00] <jml> err... reactor.callLater(0, os._exit, TIMEOUT_CODE)
[18:01] <jml> abentley: so the error handling would get a chance to run, and if it doesn't then the next thing that happens is a hard stop.
[18:01] <abentley> jml: works for me.  Works for you?
[18:01] <jml> abentley: if it works at all :)
[18:04] <jml> hmm. the test passes, but I suspect it's logging two TimeoutError oopses.
[18:04] <jml> (really hard to actually check for that)
[18:12] <jml> abentley: yeah. it logs two oopses in that case.
[18:14] <abentley> jml: I guess we want that, since the first oops isn't guaranteed to work?
[18:15] <jml> abentley: maybe. I honestly don't know. Two oopses seems less good than one. But maybe the extra information is worth it.
[18:16] <abentley> jml: You could use a different exit status if the exception handler succeeds.
[18:16] <jml> I don't know how to log oopses safely from the signal handler (both because of signal handling but also because logging an oops requires a substantial amount of infrastructure that might not be present, such as parsed config)
[18:16] <jml> abentley: hmm.
[18:17] <jml> abentley: I'll give that a try.
[18:18] <jml> abentley: this is approaching the complexity of the "set some state" solution I discussed the other day, though
[18:24] <jml> abentley: I can't make this work without making a mess.
[18:26] <abentley> jml: I think getting the traceback is pretty important, so I can accept the two-oops solution.
[18:26] <jml> abentley: OK. I'll add some comments.
[18:32] <jml> abentley: http://pastebin.ubuntu.com/584950/
[18:32] <abentley> jml: r=me.
[18:32] <jml> abentley: thanks.
[18:45] <LPCIBot> Project windmill build #99: STILL FAILING in 44 min: https://lpci.wedontsleep.org/job/windmill/99/
[19:29] <LPCIBot> Project windmill build #100: STILL FAILING in 43 min: https://lpci.wedontsleep.org/job/windmill/100/
[19:37] <leonardr> benji, i'm having a problem receiving zope events. can you help?
[19:37] <leonardr> lp:~leonardr/lazr.restful/449561
[19:37] <benji> leonardr: sure, looking now
[19:38] <leonardr> look at EventTestCase in test_webservice.py
[19:50] <benji> leonardr: ahh, the zope.component subscriber (the one that takes the super simple events from zope.event and dispatches the interface based events) isn't wired up in the test
[19:50] <benji> let me see how you do that
[19:53] <benji> well, that was at least part of the problem, but it's still not working
[20:03] <leonardr> benji: i know it's working in webservice.txt, you might look at that
[20:08] <benji> leonardr: here you go http://pastebin.ubuntu.com/585015/
[20:08] <leonardr> benji, thanks, will look in just a minute
[20:09] <benji> also, the zope.component.eventtesting.getEvents function would probably simplify your tests a bit (remove the need to register your own handler)
[20:12] <lifeless> 'sender-time Sent at 4:56 AM (UTC). Current time there: 8:10 PM'
[20:13] <deryck> later on, everyone.
[20:14] <leonardr> jcsackett: very quick: https://code.launchpad.net/~leonardr/lazr.restful/fix-test-failures/+merge/54773
[20:14] <jcsackett> leonardr: looking now.
[20:18] <jcsackett> leonardr: r=me
[20:18] <leonardr> jcsackett: i'm still getting a failure. it's that damn list of things that need to be sanity-checked
[20:18] <leonardr> it needs to be cleared out all the time, not just for those tests
[20:19] <jcsackett> leonardr: ok. feel free to ping me after uploading those changes.
[20:19] <leonardr> jcsackett: ok, i think i know how to do it
[20:41] <jcsackett> leonardr: how does one go about exporting something only into devel?
[20:41] <leonardr> jcsackett: for an entry or field, you use as_of="devel"
[20:41] <leonardr> for a named operation, you use @operation_for_version("devel")
[20:41] <leonardr> this is once my branch lands
[20:41] <leonardr> ah, it just landed, so my advice is accurate
[20:42] <jcsackett> but until your branch lands it's not doable?
[20:42] <jcsackett> ah, excellent.
[20:43] <leonardr> before my branch landed it was doable but ugly
[20:48] <lifeless> ok, logs have updated
[20:48] <lifeless> I see 2011-03-24 20:07:25 INFO    Notifying<EMAIL_ADDRESS>about bug 741821.
[20:48] <_mup_> Bug #741821: "Mute bug mail" in new bug reports is odd <confusing-ui> <story-better-bug-notification> <Launchpad itself:Triaged> < https://launchpad.net/bugs/741821 >
[20:48] <lifeless> and the initial one was
[20:48] <lifeless> 2011-03-24 15:45:43 INFO    Notifying<EMAIL_ADDRESS>about bug 741821.
[20:48] <_mup_> Bug #741821: "Mute bug mail" in new bug reports is odd <confusing-ui> <story-better-bug-notification> <Launchpad itself:Triaged> < https://launchpad.net/bugs/741821 >
[20:49] <lifeless> thats 4h20 minutes later
[20:49] <lifeless> the bug activity is
[20:49] <lifeless> 2011-03-24 15:32:53	Andrea Corbellini	bug			added bug
[20:49] <lifeless> 2011-03-24 15:56:44	Graham Binns	tags		confusing-ui story-better-bug-notification
[20:49]  * jcsackett nods. that works with what we've seen.
[20:49] <lifeless> 2011-03-24 15:56:48	Graham Binns	launchpad: status	New	Triaged
[20:49] <lifeless> 2011-03-24 15:56:52	Graham Binns	launchpad: importance	Undecided	High
[20:49]  * gmb needs to stop "Graham" and "Binns" from highlighting
[20:50] <lifeless> so 20 minutes would have been reasonable
[20:50] <lifeless> the fact that the interval is 4h20 minutes makes me wonder
[20:50] <lifeless> is there a 4 hour grace period on actions being reverted or something ?
[20:50] <lifeless> gary_poster: ^
[20:51] <gary_poster> I was just talking in ops about all this...
[20:52] <gary_poster> lifeless, no
[20:52] <lifeless> oh
[20:52] <lifeless> CHANNEL FAIL
[20:53] <gary_poster> :-)
[20:53] <bac> hi sinzui, you have a minute to chat about menus
[20:53] <lifeless> sorry
[20:53] <gary_poster> np
[20:54] <jkakar> This is a curious position to be in: You are the owner of this team. You are not currently an active member.
[20:54] <jkakar> I guess one never gives up ownership of a team...?
[20:54] <jkakar> https://launchpad.net/~clouddeck
[20:58] <lifeless> jkakar: ownership can be handed off
[20:59] <jkakar> lifeless: Ah, okay.  That should probably happen in this case.
[20:59] <jkakar> lifeless: Aha, found it... thanks for the hint. :)
[21:01] <sinzui> bac: I will in 2 minutes
[21:04] <sinzui> bac: mumble?
[21:04] <bac> sinzui: yes please
[21:11] <lifeless> is anyone fixing the db-devel conflict ?
[21:11] <jcsackett> lifeless: is there a new one? bigjools or jml killed one awhile ago.
[21:22] <leonardr> jcsackett: ok, take another look. i made the sanity check responsible for cleaning up after itself, and i added code to the test framework to wipe any test that imported a module without running the sanity check
[21:27] <jcsackett> leonardr: while the while len > 0: pop? wouldn't just reassigning to [] be faster? the contained objects lose their reference all the same so should still be cleaned up normally...
[21:28] <leonardr> jcsackett: i would love to reassign to [], but that doesn't work
[21:28] <lifeless> jcsackett: leonardr: cleaning a list ?
[21:28] <leonardr> yeah
[21:28] <lifeless> del list[:]
[21:28] <jcsackett> leonardr: ooh, that works nicely.
[21:29] <jcsackett> lifeless, rather.
[21:29] <lifeless> also spellable as list[:] = []
[21:29] <lifeless> but I'd use del
[21:29] <leonardr> change made
[21:29] <jcsackett> leonardr: does that work in your instance?
[21:30] <leonardr> yeah
[21:30] <jcsackett> awesome.
[21:30] <jcsackett> r=me,
[21:30] <leonardr> i just can't change the reference
[21:30] <jcsackett> leonardr: ah, right.
[21:30] <jcsackett> well, with the del, all seems well by me. land it. :-)
[21:30] <leonardr> ok
[22:03] <sinzui> wgrant:  mumble?
[22:17] <wallyworld> leonardr: sorry i missed you this morning - got sucked straight into a prod incident. saw your mp comment. thanks. can you tell me how to run the tests?
[22:17] <leonardr> wallyworld: bin/test should work
[22:17] <leonardr> if you don't have bin/test you need to run 'python bootstrap.py; bin/buildout'
[22:18] <wallyworld> leonardr: i there was no bin/test. i started running buildout etc and it went to download all this zope stuff so i killed it cause i was using my 3g modem at the time
[22:19] <wallyworld> i will let it finish running the next time
[22:20] <lifeless> sinzui: you wanted to talk about the person merge branch I reviewed
[22:20] <leonardr> wallyworld: ok, do this too:
[22:20] <leonardr> create a ~/.buildout/default.cfg
[22:20] <leonardr> mine looks like this
[22:20] <leonardr> [buildout]
[22:20] <leonardr> eggs-directory=/home/leonardr/.buildout/eggs
[22:20] <leonardr> download-cache=/home/leonardr/.buildout/download-cache
[22:21] <leonardr> everything it downloads will be stored so it will only download once
[22:21] <sinzui> lifeless: Yes please
[22:21] <leonardr> not for every branch
[22:21] <lifeless> sinzui: did you want voice or irc or ... ?
[22:21] <wallyworld> leonardr: ah, that's what i need. thanks
[22:21] <sinzui> lifeless: I am staring skype
[22:22] <lifeless> kk
[22:22] <wallyworld> leonardr: i'm working on the prod incident atm but will make the changes you suggested and let you know. i should be able to make myself available for a standup tomorrow morning to hopefully finalise stuff before you go
[22:23] <leonardr> ok, great
[22:23] <leonardr> talk to you then
[22:39] <wgrant> Ooh, explicit API versioning.
[22:39] <wgrant> Excellent!
[23:14] <lifeless> sinzui: mailed.


[20:38] <sirgad> hey. either of you know how to modify gconf settings on a LiveCD in order to change certain default values?  I'm using the terminal in UCK.


[20:50] <jml> mwhudson, hello
[20:54] <thumper> jml: mwhudson is not really feeling well :(
[20:54] <thumper> jml: where are you?
[20:55] <thumper> jml: Dallas?
[20:57] <jml> thumper, I am.
[23:26] <thumper> rockstar: I need you
[23:27]  * thumper fires off an ec2 test run
[23:39] <rockstar> thumper, hi
[23:39] <rockstar> jml, where are you in the hotel?  At the bar?
[23:39] <jml> rockstar, very close to it, yet.
[23:40] <rockstar> jml, "in the vicinity of the bar?"
[23:40] <jml> rockstar, I'm not leaning on it, downing my sixth for the evening and asking them to play "Pianoman"
[23:40] <jml> rockstar, but if you look at the TV to the left of the bar and then look down and somehow manage to tear your gaze away from sidnei, you'll see me.
[23:41] <rockstar> jml, I'm in my hotel room, being anti-social.
[23:41] <jml> rockstar, most of us in my area are being asocial.
[23:42] <rockstar> jml, I wasn't sure you were going to be here.  If you have any super mega hacking sessions in the evening this week, please let me know.
[23:43] <jml> rockstar, will do
[23:43] <jml> rockstar, I hope I get to have one
[23:43] <jml> rockstar, I've reviewed some branches already
[23:43] <jml> but no real hacking yet
[23:43] <jml> lots of emails
[23:44] <rockstar> Yea, deryck and I had a pretty productive day yesterday, but we're just passively hacking now, watching Transformers 2.
[23:44] <jml> an excellent movie to ignore


[00:00] <ogra> slangasek, arm images dont use OO.o, we need to make sure OO.o gets built on one of the new machines, the old ones segfault randomly
[00:01] <slangasek> which ones are the new ones?
[00:01] <ogra> slangasek, but that shouldnt hold up beta
[00:01] <ogra> ubuntu-netbook and ubuntu-server are the ones we test
[00:02] <ogra> netbook has the new weboffice stuff in the image, while its important that we have OO.o building and running for final it doesnt impact the milestones anymore
[00:03] <ScottK> It's still on the KNR armel images.
[00:03] <ogra> slangasek, oh, you mean the new builders ? (sorry, i'm very tired) lamont should be able to tell, i think gourd is one of the new ones
[00:03] <ogra> cushaw sounds new as well
[00:04] <slangasek> previous build was on buttercup - do you know if that's new or old?
[00:05] <ogra> not of the top of my head, lamont is really the safest person to ask here, he just set up a set of new builders
[00:05] <slangasek> lamont: ping
[00:06]  * ogra is totally swamped in omap stuff since a while
[00:08] <ogra> slangasek, do you plan a d-i upload before beta ? (i saw you bumped the ABI for armel arches and the commit i did today for omap would be helpful for server images)
[00:08] <slangasek> server images?
[00:09] <ogra> we build netbook, servar and netinst images for all arm arches
[00:09] <lamont> ogra: new (bbg3): buttercup, cushaw, gourd
[00:09] <ogra> *server
[00:10] <slangasek> ogra: ^^ then OOo is FTBFS on the new armel buildds.
[00:10] <lamont> ogra: and to come: acorn crabapple satinash hubbard sycamore hawthorn
[00:10] <lamont> though one of those will be livecd builds
[00:10] <ogra> slangasek, given the kernel is only half way there (still waiting on amit here to do teh final fixes) i'd be fine to have at least a server image atm
[00:11] <ogra> lamont, can you give back OO.o to build on one of the old buildds to check if its probably an issue with the new setup ?
[00:12] <slangasek> ogra: building server images is an artifact of how the cronjobs are set up, no one has mentioned to me that we're supposed to support armel server images; why do you care if those are working?
[00:12] <lamont> ogra: with some sobbing, yes
[00:12] <slangasek> (I had no plans to upload d-i because I was unaware anyone cared - you can upload it, though)
[00:12] <ogra> slangasek, we dont *suuport* them per se :) they are just the easiest thing to get working to have something at all
[00:13] <ogra> slangasek, currentl kernel prob with omap is that HID is screwed, so live images are a no go on an arch that only has USB input
[00:13] <ogra> *current
[00:13] <slangasek> heh
[00:13] <lamont> ogra: so we know it'll fail on buttercup?
[00:13] <ogra> lamont, apparently
[00:13] <slangasek> lamont: yes
[00:14] <lamont> just for the record, this isn't trivial.
[00:14] <slangasek> what isn't?
[00:14] <lamont> forcing the m achine it lands on
[00:14] <slangasek> oh, giving back on an old one
[00:14] <ogra> well, its not urgent that we have oo.o for beta, but i think it seems to show a potential buildd prob
[00:14] <slangasek> I don't see the point in doing it
[00:14] <wgrant> lamont: I suppose you have to flip them all onto manual, tweak a build score, and flip one back onto auto? Ew.
[00:15] <ogra> well, probably something for next week anyway, given that all old machines are totally busy atm
[00:15] <lamont> wgrant: step 0: nuke the current build to get it back into failed
[00:16] <ogra> yeah, dont nuke gcc
[00:16] <lamont> which actually is just a matter of waiting for the build to get to that step
[00:16] <wgrant> True.
[00:16] <lamont> the easy part is landing it on an old machine - I have some of those that are trying to be retired
[00:22] <ogra> slangasek, when did you give it back last time ?
[00:23] <ogra> the log i checked today seems to have failed in a different place
[00:23] <ogra> (today like about 12-14h ago)
[00:24] <lamont> it does help to have a spare buildd in your back pocket.
[00:25] <lamont> huito is building it, but ogra... I'm thinking you really want it to fail there, too.
[00:25] <ogra> yeah, i really hope it does
[00:25] <slangasek> ogra: I think I last gave it back before that
[00:26] <ogra> hmm, k, then i might misremember, i cant remember seeing anything about localedata around the segfault line
[00:32] <ogra> slangasek, d-i is in the queue
[00:32] <slangasek> ok
[00:32] <lamont> at any rate,  afk for a goodly while, I think
[03:40]  * slangasek gets the isotracker a-movin'
[04:08] <ScottK> Ah my, he's not done.
[04:12] <ScottK> Ah/Oh
[04:15] <slangasek> who?
[04:27] <ScottK> slangasek: zul.  This big slew of Universe uploads is all zul doing mysql rebuilds.
[04:28] <slangasek> ah
[04:28] <slangasek> why are mysql rebuilds needed, OOI?
[04:28] <slangasek> (I don't see anything on NBS)
[04:36] <ScottK> Maybe he's trying to get everything to 5.1.
[04:36] <ScottK> Not sure.
[04:38] <slangasek> mmk
[04:39] <slangasek> GrueMaster: FWIW, ARM candidate images for beta2 have started building, but with the addition of omap, I guess that'll take another 2 hours longer so won't be ready 'til morning
[04:39] <ScottK> If stuff isn't seeded, I'm just pushing Universe through.  I view needing the push as a workaround to an LP limitation because the unseeded part of Universe isn't frozen.
[04:40]  * slangasek nods
[04:41] <slangasek> speaking of which, is there a reason chromium-browser is still in the queue?  Does somebody have that seeded somewhere?
[04:42]  * wgrant points at the augmented queue, with package sets.
[04:42] <ScottK> I thought it was seeded on armel, but I wasnt' sure
[04:42]  * slangasek chuckles
[04:42] <ScottK> wgrant: Very helpful.
[04:42] <ScottK> Unfortunately I've discovered as a result that package sets are manually maintained at the moment and not always in sync with the seeds.
[04:43] <wgrant> YAY
[04:43] <ScottK> That's a limitation of the current initial implementation.  Not "the plan".
[04:43] <slangasek> ScottK: chromium-browser was investigated for armel this cycle, and in the end they stuck with firefox
[04:43] <wgrant> Ah, good.
[04:43] <ScottK> slangasek: OK.  Thanks.  I'll accept it then.
[04:44] <ScottK> slangasek: I left twm there because it's a pending MIR issue.  I'm not sure Depends -> Suggests for menu is a great idea.
[04:45] <ScottK> I didn't get a chance to see what twm uses it for.
[04:45] <slangasek> twitch
[04:45] <slangasek> has someone opened an MIR bug, or is it just currently in components-mismatches?
[04:45] <ScottK> There's a MIR bug.  It's referenced in debian/changelog
[04:46] <ScottK> The MIR is ~approved too.
[04:46] <ScottK> Read the bug and then double twitch.
[04:47] <slangasek> meh, I think the right answer is to b-d on metacity instead of twm
[04:47] <slangasek> promoting a wm just to have it for a java test suite seems absurd to me
[04:47] <ScottK> Thus the double twitch.
[04:51] <ScottK> slangasek: Are you going to write in the bug and reject it?
[04:51] <slangasek> ScottK: I've commented the bug, but I'm not ubuntu-mir
[04:52] <slangasek> so I'll wait for their decision before accepting/rejecting the package
[04:52] <ScottK> OK.
[04:52] <slangasek> in the meantime, AFK
[05:42] <GrueMaster> slangasek: What, you mean I can't start testing until after midnight?  Aww.  :P
[07:23] <ara> morning all!
[07:46]  * slangasek waves
[07:48] <ara> hey slangasek
[07:58] <ttx> slangasek, ara: o/
[08:05] <mvo> ttx: good morning, not sure you have noticed, I added the server-tasks upgrade test profile. karmic->lucid seems to have a conffile prompt in bind9, otherwise it looks good
[08:06] <ttx> mvo: no, haven't had a look yet. That sounds good, thanks. Do we have a bug about the bind9 thing or do you want me to look into it ?
[08:06] <mvo> ttx: I have not checked for bugs or details yet, I do a app-install-data update now, then I can check it out
[08:27] <slangasek> GrueMaster: arm netbook is up
[08:28] <slangasek> ara: should the UbuntuGlobalJam milestone be hidden on the tracker?
[08:29] <ara> slangasek, indeed, I'll do it
[08:29] <slangasek> thanks
[09:19] <pitti> slangasek: still okay to sync a new tzdata into lucid at this point, or shall I do it after beta-2? (just two simple DST rule updates, bug 550157)
[09:35] <slangasek> pitti: if it's not urgent, please wait until after beta2 or until we have to reroll for something else
[09:35] <slangasek> http://qa.ubuntu.com/reports/ogasawara/weatherreport.html is a lot easier to read when it lists 0s instead of 1s
[09:35] <pitti> slangasek: not that urgent; time will be wrong in Tunesia and Pakistan, but it's certainly not worth a re-roll
[09:36] <pitti> yes, understood
[09:36] <slangasek> will be wrong immediately?
[09:36] <pitti> yes, the changes got effective two weeks ago in Tunis
[09:36] <slangasek> yuck :/
[09:36] <pitti> oh, Pakistan only changes April 15, so that's still ok
[09:37] <pitti> slangasek: but we'll provide an updated tzdata in lucid, so on an installed system you can just upgrade
[09:37] <slangasek> yeah
[09:37] <pitti> slangasek: I'd only sync it if you were planning a re-roll anyway
[09:37] <slangasek> I guess the SRUs are more important for production
[09:37] <pitti> right, I'm doing them right now
[09:37] <pitti> +# > On Thursday (2010-03-25) it was announced that DST would start in
[09:37] <pitti> +# > Pakistan on 2010-04-01.
[09:37] <pitti> How the heck can governments do things like that??
[09:38]  * pitti stops grumbling and continues to fire SRUs
[09:39] <slangasek> they can do things like that because there's no physical law that ensures good sense in government :)
[09:40] <pitti> right, and instead we get bug comments "24 hours later, still not assigned... and importance "undecided".... Viva Ubuntu ! Pfffffff...... :-(" ...
[09:41] <pitti> slangasek: want me to process those SRUs myself?
[09:42] <slangasek> yeah, feel free
[09:43] <slangasek> comments> those are the kind of people I tell that they should be complaining to their government for being irresponsible
[09:45] <ttx> cjwatson: "splash" is still present on the beta2 candidate server install
[09:45] <ttx> pitti: sounds like an april 1st joke
[09:45] <pitti> ttx: sadly not; many countries do that unfortunately
[09:47] <ttx> slangasek: for some reasons, the samba-server task installs winbind, so the pam_winbind profile borkenage affects the resulting install -- I'm looking at where that comes from
[09:48] <slangasek> ttx: I would expect a samba server task to include winbind
[09:49] <slangasek> I'd rather focus on understanding the profile error, which I have yet to reproduce here despite having pam_winbind configured
[09:49] <ttx> slangasek: right
[09:49] <slangasek> I really need someone who's seeing this problem to post me their full /etc/pam.d/common-* for analysis
[09:49] <ttx> I can reproduce on a bare ISO+samba-server task install, cannot log in
[09:50] <ttx> I can provide that info
[09:50] <slangasek> including on console?
[09:50] <ttx> yes.
[09:50] <slangasek> ok
[09:51] <ttx> just a sec, booting single-user mode and packing that up for you
[09:51] <slangasek> thanks
[09:54] <ttx> the missing piece of the puzzle might be that pam_smbpass is also active
[09:54] <ttx> (or not)
[09:55] <slangasek> I've been running with both pam_winbind and pam_smbpass active for months
[09:55] <slangasek> no errors
[09:55] <slangasek> I've just stripped it down to unix+winbind; still no errors
[10:00]  * ttx grumbles -- for some reason I can't login even with winbind disabled
[10:00]  * ttx digs deeper
[10:01] <slangasek> ah :)
[10:06] <ttx> hmm, I must have forgotten the password I used in my ISO install (or mistyped it... twice??!), let me re-reproduce cleanly :)
[10:07] <ttx> or.. maybe the password was not set correctly at the end of the install on top of the borken stack.
[10:09] <ttx> ew, and the primary user is not added to sudoers group either
[10:10] <slangasek> check for a password hash in /etc/shadow?
[10:10] <slangasek> (if you haven't already clobbered it)
[10:10] <ttx> I clobbered it
[10:10] <ttx> but I'm reproducing on another box
[10:10] <slangasek> ok
[10:10] <slangasek> I was musing that this might be a possibility
[10:11] <slangasek> but that means the installer isn't letting the user know about failures setting the password?
[10:12] <ttx> I'll have a look at the install console and see if there is something showing, but yes, I'd suspect the installer wouldn't let you know about it
[10:13]  * ttx reboots in single-user mode to get sufficient privileges to access that profiles tarball
[10:14] <slangasek> I expect better than that of the installer :)
[10:18] <ttx> took longer than expected, but here you go:
[10:18] <ttx> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/546874/comments/17
[10:18] <ttx> I'm reproducing on an unclobbered new install to look at the state of the passwd file
[10:20] <ttx> slangasek: confirmed, no passwd hash entry on the regular user in /etc/shadow at the end of the install
[10:20] <slangasek> yay
[10:22] <ttx> also the installer logs show that it fails
[10:22] <ttx> chpasswd pam_winbind failure
[10:22] <ttx> WBC_ERR_WINBIND_NOT_AVAILABLE
[10:23] <ttx> warning: /usr/lib/finish-install.d/06user-setup returned error code 1
[10:23]  * slangasek nods
[10:23] <ttx> but that's apparently not a blocking error.
[10:26] <ttx> slangasek: so the "even on console" answer above might be biased: doing it "from ISO" like this will end up with no passwd set, so you obviously can't login even on console.
[10:27] <ttx> that doesn't mean the pam stack would prevent you from doing so, given that there is a good passwd entry set.
[10:27]  * ttx checks on an already-installed system
[10:30] <slangasek> ttx: so the fix to winbind is pretty straightforward, I think
[10:30] <slangasek> 1) call pam-auth-update in winbind.postinst
[10:30] <ttx> (and prerm)
[10:31] <slangasek> 2) Password-Type: Primary instead of Password-Type: Additional in debian/winbind.pam-config
[10:32] <ttx> ah, so the auth stack was never wrong, just the password stack
[10:32] <ttx> with the ISo installs blurring the line
[10:34] <ttx> slangasek: if that's all it takes, I'll assign me and target to beta2, if that's ok with you
[10:35] <mvo> ttx: bug #556332 - bind9 is acting strange here, feedback welcome
[10:35] <mvo> ttx: not a showstopper or anything, but really odd IMO
[10:35] <ttx> mvo: I'll add it to the hit list
[10:35] <ttx> mvo: thanks
[10:36] <slangasek> ttx: sure, go ahead
[10:37] <slangasek> (still doesn't explain some people who are reporting *recent* problems being able to log in, but we can at least fix the installer case this way)
[10:38] <ttx> most people report passwd-changing issues. The ones with login problems are usually beta ISo testers
[10:38] <ttx> so that seems coherent
[10:39] <slangasek> re: the prerm, I've already committed the fix for that in Debian Samba svn; but it's bound up now with the question of whether Debian is doing 3.4 or 3.5 for squeeze, so you'll need to cherry-pick
[10:40] <ttx> ok
[10:49] <mvo> ttx: and bug #556343
[10:49] <mvo> ttx: more important as it causes a real failure
[11:01] <slangasek> ttx: bug #546874's submitter claimed that logins were broken, only after an upgrade, and he installed from a desktop - I don't see any way that winbind would get pulled in immediately as part of a desktop install so the initial password setting should still be correct, and anyway we have his statement that it broke only after upgrade
[11:01] <slangasek> so there's some other bug here, still
[11:03] <ttx> ah, yes, got lost in duplicates.
[11:06] <ttx> slangasek: did you get some answer about removing the wine rdepends ?
[11:11] <cjwatson> ttx: still catching up from holiday - syncing and having a look, may take a while
[11:20] <ttx> cjwatson: ack
[11:20] <slangasek> ttx: no
[11:21] <slangasek> ttx: I also didn't file a bug about it; would you care to, or should I do so in the morning?
[11:21] <ttx> slangasek: I'll do it
[11:21] <cjwatson> that winbind failure in user-setup above might well cause some odd knock-on effects, despite not blocking
[11:21] <slangasek> python-pkg-resources> curses, one o-o-d package on all ISOs now
[11:22] <slangasek> cjwatson: it causes knock-on effects like a successful install w/o an authenticatable user, apparently...
[11:24] <cjwatson> yes, I can believe that.  needs rather better error handling, but for now we need to fix the failure anyway ...
[11:24] <slangasek> yep
[12:42] <ttx> slangasek: here is the winbind fix ^
[13:17] <ScottK> slangasek: Last week you removed libannodex, but left pyannodex.  Would you please remove that too?
[13:17]  * ScottK reports a bug.
[13:19] <cjwatson> ttx: is there a bug open for the server splash still not working?  (if not, don't bother filing one, just want to check if I should be closing one)
[13:21] <ttx> cjwatson: no, I just commented on the existing one, wasn't sure which task I should reopen, if any
[13:21] <ttx> I was wondering if something wasn't just waiting for a respin to trigger
[13:23] <cjwatson> no, it's a bug
[13:24] <cjwatson> I'll reopen the existing bug, then
[13:24] <cjwatson> the "could not write bytes: broken pipe" bit is unrelated, but I think there's already a bug somewhere for that
[13:29] <cjwatson> parted: not needed for beta-2
[13:57] <cjwatson> could somebody please review grub-installer?  RC IMO, to fix ttx's problem above
[13:59] <ttx> yes, we definitely need the potentially-final server boot experience in beta2 for testing :)
[13:59] <cjwatson> it also needs another debian-cd change, which I have prepared and ready to go
[14:09] <ScottK> cjwatson: Looks good to me.  Accepting.
[14:10] <ScottK> Done.
[14:12] <cjwatson> ScottK: thanks
[14:15] <ScottK> cjwatson: I know there isn't any documentation in the package to be affected, but is there online documentation about customization that needs updating for splash=false instead of nosplash?
[14:17] <cjwatson> ScottK: I wouldn't expect so - nosplash is very new, on the order of days
[14:17] <ScottK> OK.  Thanks.
[14:18] <ScottK> "If your documentation is that bleeding edge, you need to be paying attention"
[14:24] <ttx> cjwatson: could you respin a Server ISO / beta2 candidate whenever that fix lands ? Also the samba in the queue (unbreaking the samba-server task) would be good to have in the next candidate.
[14:29] <cjwatson> planning to
[14:29] <cjwatson> would prefer somebody more domain-competent to review samba, though
[14:35]  * ScottK is fixing quediff to work with .bz2 orig
[14:37] <ScottK> Done, so it can be used by whoever has the domain-competence to review it.
[16:02] <james_w> any thoughts on https://bugs.edge.launchpad.net/ubuntu/+source/xpdf/+bug/556483?
[16:02] <james_w> no new features, but rewritten packaging, would that require an exception?
[16:05] <ScottK> james_w: Generally yes.
[16:49] <Riddell> ev: thanks for fixing bug 556180
[16:49] <ev> sure thing
[16:59] <Riddell> ev: planning a ubiquity upload at some point?
[17:00] <ev> Riddell: yeah.  I was hoping to get Ken's timezone map changes in, but as those will require an exception, I might as well do an upload now so that your fixes don't block on that.
[17:01] <Riddell> ev: changing the SVG requires a UI freeze exception?
[17:01] <ev> I had assumed so
[17:02] <Riddell> doesn't seem like a big enough change to need that, I doubt we have many screenshots of the map with India or Pakistan selected
[17:03] <ev> Russia as well, but noted
[17:03] <Riddell> Russia claims Kashmir?
[17:03] <cjwatson> some of Russia's timezones changed a bit recently
[17:04] <cjwatson> I agree, I think it's worth notifying the doc team but I don't think it needs freeze paperwork really
[17:04] <ev> okay cool, I'll take care of this first then
[17:10] <ScottK> Bug #556629 is potentially significant.
[17:27] <ev> if anyone has some free cycles, I'd appreciate a review of bug 554570 and bug 554976
[17:45] <ev> Riddell: ubiquity 2.2.15 is in the queue
[17:51] <Riddell> ev: accepted!
[18:21] <mvo> http://people.ubuntu.com/~mvo/automatic-upgrade-testing/current/ looks not that great currently (but server-tasks and lts-ubuntu should really only be WARN and not FAIL, the bugs are not that serious)
[18:25] <GrueMaster> Riddell: Does this mean there will be a respin for Ubiquity 2.2.15?
[18:25] <Riddell> GrueMaster: for Kubuntu yes, probably the rest too if we want to keep the Kashmir lobby happy
[18:26] <GrueMaster> sigh.  I'm doing the ubuntu-armel testing.  Takes a lot longer than desktop or netbook due to limited resources.
[18:27] <GrueMaster> And I hate having to recompile my bug lists.
[18:32] <Riddell> such is the world of ISO testing, slow and painful
[18:32] <Riddell> surely launchpad can handle bug lists
[18:33] <ttx> slangasek: please review the samba (winbind) fix whenever you have the time, and respin server ISo / refresh beta2 server candidate when it lands
[18:34] <ttx> slangasek: ping smoser when done so that he can generate EC2 cloud image candidates
[18:35] <Riddell> ttx: not sure if slangasek is around just now, maybe another release team member should help?
[18:36] <ttx> Riddell: iirc most of them declined to review the samba as not being in their domain, but yes, anyone can help :)
[18:40] <Riddell> ttx: I accepted samba
[18:41] <ttx> Riddell: ok, so when it lands, we could use a server ISo respin/ candidate refresh, the sooner the better
[18:41] <Riddell> disabled current images in tracker
[18:42] <Riddell> ev: we want new ubuntu desktop images I take it?  I should disable those in tracker too?
[19:06] <slangasek> ttx, Riddell: samba> thanks
[19:07] <slangasek> ScottK: libannodex> yes, was going to file that bug myself prior to removal
[19:25]  * cjwatson writes an interactive version of packageset-push in the hope that that will enable him to keep up with packageset changes a bit more effectively
[19:47] <charlie-tca> Are you going to respin xubuntu?
[19:47] <charlie-tca> 7q83+TKbzFN
[19:50] <slangasek> the ubiquity changes would also apply to xubuntu, but I wouldn't think it's critical
[19:51] <charlie-tca> okay
[19:51] <cjwatson> charlie-tca: might want to change that password :)
[19:51] <charlie-tca> yeah, good thing it is for testing, huh
[19:53] <slangasek> so bug #519541 keeps getting reported as a serious bug in all the xubuntu tests, but it has no assignee?
[19:54] <charlie-tca> yup
[19:54] <charlie-tca> It completely freezes abiword, the Xubuntu default word processor. If the document is not already saved, it is lost
[19:55] <slangasek> yes, I understand it's a serious bug, that's not the question - the question is why no xubuntu dev has taken responsibility for it
[19:56] <charlie-tca> I don't know. I keep telling them about it, too.
[20:15] <slangasek> Riddell: what did kubuntu alternate need respun for?
[20:15] <Riddell> slangasek: I don't think it did, did I mark that in iso tracker?
[20:16] <Riddell> fixed
[20:16] <slangasek> ok, cheers
[20:16] <slangasek> I'm going to start the respins now
[20:16] <slangasek> assuming I'm not colliding with you :)
[20:16] <Riddell> go ahead
[20:17] <Riddell> although `ls cdimage/ftp/pool/main/u/ubiquity/*2.2.15*` is empty on antimony, I take it that's not what counts?
[20:18] <slangasek> GrueMaster: I don't think I'll respin armel netbook for the ubiquity change; I don't imagine there are a lot of ARM hardware vendors is Kashmir that are going to come after us for an inaccurate beta map
[20:18] <GrueMaster> cool
[20:18] <slangasek> Riddell: nope, antimony's mirror is updated /by/ the ISO job
[21:37] <slangasek> ev, cjwatson: any other installer issues on the horizon that look like they could be beta blockers?
[22:05] <slangasek> all respins done/posted except for DVD
[22:10] <cjwatson> slangasek: not that I've seen so far, but I've been feeling ill this evening so am not as on top of bugs as I'd like :-/
[22:12] <slangasek> understood
[22:12] <slangasek> aside from the last kubuntu issues, the ISO tracker looks (deceptively?) calm
[22:59] <kees> ScottK: are you around to push selinux and refpolicy-ubuntu for me?
[23:08]  * kees thanks mystery pusher
[23:15] <mdeslaur> lol
[23:18] <slangasek> lamont, elmo: old-releases.u.c requires a manual push, is that right?
[23:18] <slangasek> (I've dropped intrepid from releases.u.c, but I don't see it showing up on old-releases)


[06:57] <mhall119> belkinsa: ping (when you're around)
[07:19] <smaboshe> Hello!
[07:20] <mhall119> hi smaboshe
[07:20] <smaboshe> I'm researching starting a LoCo for Zambia: http://loco.ubuntu.com/about-loco/setup/
[07:20] <mhall119> that would be awesome
[07:21] <smaboshe> Indeed!
[07:21] <smaboshe> Step one is to create a team.
[07:21] <smaboshe> I understand the naming convention is to use ubuntu-CC.
[07:21] <mhall119> yup
[07:22] <smaboshe> I'm having trouble because it seems the Zambia CC is taken but is not associated to a LoCo.
[07:22] <smaboshe> https://launchpad.net/~ubuntu-zm
[07:22] <smaboshe> Any advice?
[07:22] <mhall119> ah, yeah, that's an individual's account
[07:23] <mhall119> so the ubuntu-CC rule is flexible, you should be able to use ubuntu-zm-team if you wanted
[07:24] <smaboshe> Awesome. I think that should work just as well. THank you, mhall119.
[07:24] <mhall119> np
[07:46] <smaboshe> Is the ubuntu-CC rule flexible for mailing lists as well? (Step 2 on http://loco.ubuntu.com/about-loco/setup/)
[08:20] <BobJonkman1> smaboshe: Our local chapter in Kitchener-Waterloo, Ontario, Canada is mostly known as ubuntu-ca-kw but our launchpad ID is https://launchpad.net/~ubuntu-waterloo-region
[08:20] <BobJonkman1> No-one has objected to the inconsistency
[08:27] <smaboshe> Thank you.
[09:16] <rsaoungoumi> bjr à tout le monde
[09:17] <rsaoungoumi> pour ceux qui n'ont pas encore check leur mail, juste une mise à jour informationnelle:
[09:18] <rsaoungoumi> la Release Party initialement prévu le Samedi 24 mai 2014 au Campus Numérique Francophone de Ngaoundéré aura lieu à l'Institut Universitaire de Technologie  de l'Université de Ngaoundéré  le même jour à partir de 13h00.
[12:30] <belkinsa> mhall119, pong, what's up?
[13:09] <mhall119> belkinsa: hi, I'm planning for the Ubuntu Online Summit (next UDS, plus open week and more) and I was hoping you'd be available to help us as a track lead
[13:09] <belkinsa> For what, mhall119?
[13:10] <mhall119> for http://summit.ubuntu.com/uos-1406/
[13:10] <belkinsa> No, which tract.
[13:10] <belkinsa> track*
[13:10] <mhall119> oh, Community/Advocacy
[13:10] <belkinsa> Sure.
[13:11] <mhall119> wonderful, thank you
[13:11] <belkinsa> Not a problem.
[13:12] <mhall119> I'll send out an email to all track leads once I finish getting confimation from them pointing to what needs to be done and who can do it
[13:12] <belkinsa> Alright, sounds cool.
[13:12] <mhall119> jose: PabloRubianes: read the scrollback please, I'd like to ask you both to be track leads too
[13:13] <PabloRubianes> mhall119: I am working at the time of the UDS :(
[13:13] <PabloRubianes> that's why I always ask for a saturday day of it
[13:14] <mhall119> PabloRubianes: we still need help in the leadup to it finding people and sessions and getting them scheduled, can you do that?
[13:14] <PabloRubianes> yes doing organization stuff before the event is ok
[13:15] <mhall119> great, thanks
[13:15] <PabloRubianes> I can't be part of the actual event but I can help with other staff
[13:15] <mhall119> we're going to ask the session proposer/speaker ot run their own hangouts, so there should be less work for track leads during the event itself
[13:16] <PabloRubianes> ok
[13:16] <mhall119> I'm getting 5 track leads for community too, so if one or two aren't around that's no problem
[13:16] <PabloRubianes> mhall119: I think jose is in class ATM, I'll talk to him later about this
[13:16] <mhall119> thanks
[13:18] <jose> mhall119: jono asked a month ago, I'm glad to help wherever I can :)
[13:19] <PabloRubianes> so he is not at class :P
[13:19] <mhall119> thanks jose :)
[13:19] <jose> smaboshe: send us an email to<EMAIL_ADDRESS>and we'll make sure we release it for you :)
[13:19] <jose> PabloRubianes: exam week this week, I actually just woke up :P
[13:19] <jose> I only have to go to university for two hours a day! \o/
[13:20] <PabloRubianes> great
[13:20] <PabloRubianes> jose: I am getting ready the email for the other day problem
[13:21] <jose> PabloRubianes: sounds good to me :)
[13:23] <PabloRubianes> and mhall119 thanks I was able to run the loco portal after the daker's fix, I already filed a bug and a fix for it
[13:47] <belkinsa> Can this blueprint be re-brought up at the next vUDS: https://blueprints.launchpad.net/ubuntu/+spec/community-1311-loco-projects ?  I think it would really help the LoCo community if we had other projects other than the App Dev Schools.
[13:54] <PabloRubianes> belkinsa: +1
[13:55] <PabloRubianes> having set events is great for Loco Organization
[13:58] <belkinsa> It seems that dpm himself forgotten about it or got too busy with other thungs.
[13:59] <belkinsa> Though these projects sound like Global Jam projects.
[15:00] <smaboshe> Thank you jose.
[15:00] <jose> smaboshe: no problem :) also, if you have a link for the launchpad team of the now-dead Zambia team, that would help speed up the process
[15:04] <smaboshe> jose: The link on launch pad that I found was launchpad.net/~ubuntu-zm and I've created launchpad.net/~ubuntu-zm-team. I'm happy to have whichever you decided is redundant deleted.
[15:05] <jose> smaboshe: I mean for the old team. there was an old team but I cannot find it on LP
[15:56] <smaboshe> jose: Thanks. I did not know there was an old team. If you find it first let met know so I can get in touch with them.
[19:42] <mhall119> belkinsa: feel free to propose it if you can run the session
[19:42] <belkinsa> Sure, but I think I want to ask dpm first.
[19:53] <mhall119> ok
[20:04] <belkinsa> And e-mail sent.
[20:32] <smaboshe> jose: Managed to find this forum thread requesting a LoCo for Zambia. Hope it helps - http://ubuntuforums.org/showthread.php?t=1459675


[17:14] <andrex> @seen antares
[17:14] <ubuntuhelp> antares was last seen in #ubuntu-ru 1 year, 10 weeks, 4 days, 15 hours, 58 minutes, and 22 seconds ago: <Antares> https://www.youtube.com/watch?v=Wsk868a0qhA #2 Маши - Красное Белое ☯


[00:24] <pleia2> hmm, it looks like 215 and 216 were skipped and redirect to 217
[00:25] <pleia2> but I don't think numbering should be time-based anyway, so moving forward I think it make sense to just go with consecutive numbering
[00:59] <pleia2> I have to admit I'm a bit shy about using the ubuntu-news.org links, since it's in such a state of flux
[02:47] <pleia2> nhandler: so I'm writing up summaries of the blog posts starting at the top, I figure I do this until I get tired/bored and that partially decides how far back we publish (unless of course someone else steps in)
[02:48] <pleia2> not organizing them in any way yet, I figure we do that once we have summaries
[03:46] <pleia2> well, I made it to december 14th, I think I'll cherry-pick now, if others want to fill in that's fine
[06:50] <nhandler> pleia2: I was a bit worried as well about the ubuntu-news.org links. I have no clue how we are going to keep links from breaking when we move to fridge.u.c. And great work on the summaries. I can copy/paste and sort to the wiki sometime tomorrow (I won't be around during the day, but I should be around some time in the evening)


[02:52] <blr> wgrant: think that's ready for review - sorry for the cjwatson sized diff.
[02:52] <wgrant> blr: Do you want to perhaps split the reindenting into another branch?
[02:53] <wgrant> Just create a fresh branch of devel, fix the indentation, and land that so the diff in this branch is reviewable.
[02:53] <blr> sorry, reindenting?
[02:53] <wgrant> productseries-setbranch.js at least
[02:54] <wgrant> Half the file is correctly reindented from three to four spaces.
[02:55] <blr> ah, sure.
[02:55] <blr> I'm going to blame emacs.
[02:58] <wgrant> Heh
[02:59] <blr> might as well lint it while I'm at it, this file would make douglas crockford sad.
[03:00] <wgrant> It certainly would.
[03:11] <blr> wgrant: ~blr/launchpad/trivial-fix-productseries-js-indentation
[03:11] <wgrant> blr: Too late :)
[03:11] <blr> refreshing is hard.
[03:14] <blr> wgrant: shall I resub that mp with a dependant branch, or wait for the merge.
[03:15] <wgrant> blr: Land the reindentation, then merge it into your main branch, resolve the conflicts, commit and push.
[03:16] <wgrant> (there isn't really a "wait for the merge" step, since buildbot runs *after* the merge)
[03:21] <wgrant> cjwatson: Ah, hm. Git MPs live under their target ref, but their target ref may no longer exist.
[03:21] <wgrant> eg. the launchpad:test MP on https://code.launchpad.net/launchpad/+activereviews
[10:21] <cjwatson> wgrant: Mm, it might make sense to move those directly under GitRepository, indeed.
[10:22] <cjwatson> And it would make the URLs a little less obnoxious ...
[11:40] <cjwatson> wgrant: Will be much easier after git-repository-delete lands, since that incidentally needed to add some MP-related properties to GitRepository.
[11:41] <wgrant> cjwatson: Ah good.
[11:55] <wgrant> cjwatson: I'd not really be concerned about leaving redirects.
[12:41] <cjwatson> wgrant: Perhaps not.
[21:08] <blr> wgrant: thank you for the thorough review!
[22:54] <blr> wgrant: cjwatson: this looks potentially useful https://github.com/DesertBus/sockjs-twisted/
[22:55] <blr> sockjs seems to have a sensible approach to degrading transports - haven't used it in earnest however.
[22:56] <cjwatson> entirely new to me :)
[22:58] <blr> cjwatson: anecdotally better maintained and more robust than socket.io
[23:54] <wgrant> blr: Do my issues/suggestions on the MP make sense?
[23:56] <cjwatson> https://code.launchpad.net/~cjwatson/canonical-is-puppet/webhooks-proxy-tweaks/+merge/259558
[23:56] <cjwatson> And now to bed.
[23:56] <wgrant> cjwatson: Thanks, and night.


[00:33] <samd> hi, im in the process of making my first deb package. The software im packing has no version, what version should i put?
[00:38] <arand> samd: What software is it, is it taken from a revision control of some sort?
[00:38] <arand> samd: Normally, one would use the date of the release as a stand-in version
[00:39] <samd> arand: yes, its mjpg-streamer, it was taken from the svn repository because it was the only source i found, if i download the tar.gz package from them, they use "r150" as 'version' where 150 is the last commit
[00:40] <arand> As an example I am using "lugaru-data_0~20110520.1+hge4354-1" for a game from mercurial (hg) with no versioning currently
[00:41] <samd> arand: alright, sounds good, ill use the date
[00:41] <arand> samd: So following that it would be "0~$date.1+svn150-1" or something to that effect
[00:43] <samd> arand: sounds good, thank you very much, ill continue with the packing
[00:43] <samd> arand: im following the guide from https://wiki.ubuntu.com/PackagingGuide/Basic
[00:43] <arand> samd: Alternatively r150, I think that might just be your preference
[00:45] <samd> arand: i tried that , but for some reason dh_make didnt recognized "r150" as a version, i might had it wrote wrong, but i changed the version to 1.0 just to see, and it worked.
[00:46] <arand> dh_make might be a bit more strict there.. you can always change it afterwards in the changelog though
[00:47] <arand> I meant 0~$date.1+r150-1 is also an alternative
[00:47] <samd> arand: alright, , i think i will go and try with  0~$date.1+r150-1
[00:48] <arand> (replacing $date with the date of the commit, just to note)
[00:48] <samd> yeah, something like YYYYMMDD i got that
[00:49] <tumbleweed> no need to include both a date and a commit number. one of the two will suffice
[00:50] <samd> oh ok
[00:50] <arand> I'm not sure but I've had some discussions with debian folks who are of the opinion that the revision number is not relevant at all, I personally think it is though, even in the case of hashes, ah, there we go ^ :)
[00:51] <tumbleweed> 0~YYYYMMDD-1 or 0~svn12-1 (or bzr) are both sensible versions
[00:51] <samd> i see, what does the 0~ mean?
[00:52] <arand> It allows for any kind of 0something to be a higher version than 0~something
[00:52] <tumbleweed> revision number is not a good idea for git (where the number of revisions is variable), but svn, bzr and hg have monotonic revision numbers (within a single tree, in hg and bzr, assuming no rebasing or commit removal)
[00:52] <tumbleweed> 0~ is smaller than 0
[00:53] <samd> i see
[00:53] <arand> So basically, it means that you don't have to worry about upstream releasing a <IP_ADDRESS>.0.1 version, it will always be greater than 0~
[00:54] <samd> got it
[00:55] <samd> let me try to build the package , ill probably throw out more questions as i advance.  thank you!
[00:56]  * tumbleweed is going to bed, enjoy :)
[08:29] <Laney> morning
[08:29] <Laney> (in before dholbach who isn't evne here!)
[08:30] <geser> morning
[08:30] <vish> Laney: he is at Dublin sprint, so … that might be the delay
[08:31] <Laney> vish: I am going to claim this as a victory nonetheless. :-)
[08:31] <vish> :D
[08:33] <nigelb> Laney: got a min for a PM?
[08:34] <Laney> yeah
[16:57] <nigelb> I made a mistake in the spelling of a word in the dep-3 patch tagging guidelines.
[16:57] <nigelb> Do I send a patch to debian or should I just leave it
[16:58] <Laney> the guidelines themselves?
[16:58] <tumbleweed> one presumes debian package maintainers all read the patches they receive and edit if necessary
[16:59] <tumbleweed> also, not much actulaly depends on having valid dep3 headers
[16:59] <Laney> assuming not, I'd just reply to the bug and point it out (if it's not archived)
[17:01] <nigelb> Ok, I'll add a reply to the bug
[17:13] <nigelb> \o/ DD replies back with thanks and he fixed it in git :-)
[17:19] <Laney> sweet


[01:48] <lotuspsychje> good morning
[20:26] <Bashing-om> UWN: Issue754 now available to the public: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue754 :D
[20:55] <ogra> damn ...
[20:56] <ogra> Bashing-om, i wanted to point you to https://jimangel.io/posts/automate-ubuntu-22-04-lts-bare-metal/ for UWN but missed due to work stuff
[20:57] <Bashing-om> ogra: Ouch! Looking :)
[20:58] <ogra> well, perhaps next issue 🙂 ... i just found it a remarkable post
[20:59] <ogra> (especially the hand drawings 😄 )
[21:00] <Bashing-om> ogra: As informative and nice as it is - it is not news, Generally we defer on any How-tos.
[21:00] <ogra> ah, kay