[00:00] <sinzui> wallyworld_: mumble?
[00:01] <wallyworld_> yep
[00:48] <wgrant> sinzui: Did you see the fallout from the flag-expired-memberships.py fix?
[00:51] <LPCIBot> Project windmill-devel build #143: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-devel/143/
[02:01] <timrc> lifeless, sorry, I'm a novice to lp... not sure I understand what you're saying on bug #724740.  I thought that adding the mutator was how to run business logic when the attribute is set...
[02:01] <_mup_> Bug #724740: setting a ppa private cannot be done over the API <api> <oem-services> <ppa> <Launchpad itself:In Progress by timrchavez> < https://launchpad.net/bugs/724740 >
[02:01] <timrc> lifeless, here's my code so far: http://bazaar.launchpad.net/~timrchavez/launchpad/set_ppa_private_from_api_724740/revision/13052
[02:03] <timrc> (sorry there are still some inconsistencies in the comments and no tests yet :/)
[02:03]  * timrc ducks
[02:24] <StevenK> wgrant: Most of the failures for archiveuploder look like behaviour changes in notify_spr_less()
[02:24] <StevenK> wgrant: Which I'm fixing
[02:25] <StevenK> wgrant: Running -t archiveuploader to see what the fall-out is
[02:46] <wgrant> StevenK: Hmm.
[02:51] <LPCIBot> Project windmill-devel build #144: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/144/
[02:57] <StevenK> wgrant: Hm?
[02:57] <wgrant> Indeed.
[02:57] <wgrant> !
[02:59] <StevenK> wgrant: Down to one failure
[02:59] <wgrant> StevenK: But who knows how many you broke in Soyuz :)
[02:59] <wgrant> Anyway, let me review your diff.
[03:00] <StevenK> I have local changes
[03:00] <lifeless> timrc: hi
[03:00] <StevenK> Including putting back sanitize_string :-(
[03:00] <wgrant> StevenK: Why did the abomination need to return?
[03:00] <lifeless> timrc: mutators can be used yes, but if we need it always then just using a property is better
[03:02] <StevenK> wgrant: Since I can't call guess_encoding on a unicode string, and the mail text seems to change
[03:02] <StevenK> For some tests it's unicode, and others it's ascii
[03:02] <wgrant> StevenK: It'll automatically become unicode when a unicode is interpolated into it.
[03:02] <wgrant> Because fuckyeah Python 2.
[03:03] <wgrant> StevenK: This indicates that there are unicode-safety bugs.
[03:03] <wgrant> StevenK: It should either always be a unicode or never be.
[03:04] <StevenK> wgrant: Then there likely already were
[03:04] <wgrant> Sure.
[03:04] <StevenK> r13103 pushed
[03:12] <wgrant> Hm.
[03:12] <wgrant> The branch is shorter now?
[03:12] <wgrant> Interesting.
[03:12] <wgrant> StevenK: notify_spr_less seems to assume there's always an archive.
[03:13] <wgrant> But that's not the case.
[03:13] <wgrant> Or at least it shouldn't be.
[03:13] <wgrant> StevenK: Perhaps s/notify_spr_less/reject_changes_file/?
[03:14] <wgrant> I'd also continue to encourage you to remove get_status.
[03:15] <StevenK> Oh, and just replace it with a dictionary?
[03:23] <wgrant> The dictionary, yeah.
[03:23] <wgrant> I'm doing a proper rereview now.
[03:23] <StevenK> I've done those two suggestions locally
[03:23] <wgrant> ACTION_DESCRIPTIONS[action] is not much worse than get_status(action) :)
[03:23] <wgrant> Thanks.
[03:24] <StevenK> The only test that still fails is testSourcePackageRecipeBuild_success_mail. Didn't poolie break that on purpose?
[03:25] <StevenK> Ah, no. I've broken it so it sends mail
[03:30] <StevenK> Ahh. I can't check PU.getSourceBuild()
[03:30] <StevenK> :-(
[03:32] <timrc> lifeless, this may sound dumb but when you say property are you referring to Python's @property? just making sure I'm understanding you correctly?
[03:35] <StevenK> wgrant: I have those two changes to push, along with the fix for SPRB_success_mail.
[03:38] <jtv-afk> hi wallyworld_
[03:39] <wgrant> StevenK: I'm reworking _sendNotification
[03:39] <StevenK> wgrant: Oh, you're going to give me a patch?
[03:39] <wgrant> Yes.
[03:40] <wgrant> 'cause I was about to shred it in the review.
[03:40] <wgrant> Decided I would be a bit kinder.
[03:40] <StevenK> Who are you, and what have you done with the real wgrant?
[03:43] <wallyworld_> jtv-afk: hello
[03:43] <jtv-afk> Oh, old nick
[03:43] <jtv> wallyworld_: any reviews you need me to mentor?
[03:44] <wallyworld_> jtv: thanks for asking. i assigned 2 to you. did you not get the email?
[03:44] <StevenK> That '- ' was annoying me
[03:44] <jtv> wallyworld_: Probably.  But email is one of those "it's got to be in there somewhere" things.
[03:44] <wallyworld_> :-)
[03:48] <jtv> Ah, there they are.
[03:53] <wgrant> StevenK: Slow tests :(
[03:53] <wgrant> But they seem happy with my +11/-53 so far.
[03:56] <StevenK> Crumbs!
[03:57] <StevenK> wgrant: My local branch has all of the archiveuploader tests passing
[04:00] <wgrant> StevenK: Have some comments.
[04:04] <StevenK> wgrant: Your commit messages makes me sad
[04:05] <wgrant> StevenK: It sucked years before you got to it.
[04:05] <StevenK> True
[04:06] <lifeless> timrc: yes, I am
[04:06] <wgrant> StevenK: send_mail/_sendMail/_sendNotification/send_message still seem like they're designed to confuse me. Let's see if we can merge/rename some of them.
[04:07] <wgrant> And they're not to be confused with sendmail(), which does the actual work!
[04:08] <StevenK> wgrant: I'm thinking about solving the two calls to _sendNotification in notify()
[04:08] <StevenK> The only difference is the summary
[04:08] <wgrant> send_mail can also easily be merged into _sendNotification.
[04:10] <StevenK> wgrant: You say the logging of the mail is still duplicated -- however the level is different?
[04:11] <wgrant> ... huh.
[04:11] <wgrant> Make it all debug.
[04:11] <wgrant> If you're doing a dryrun you should be using -v anyway, surely.
[04:13] <wgrant> StevenK: What's the difference between the two _sendNotification calls? rejected doesn't send the file summary with OK/NEW/etc.?
[04:13] <wgrant> That seems sort of trivial to sort out.
[04:14] <StevenK> wgrant: summarystring for !rejected, summary_text for rejected
[04:14] <StevenK> Only
[04:16] <wgrant> StevenK: Do you like my slight _sendNotification simplification?
[04:16] <StevenK> I do
[04:16] <timrc> lifeless, gotcha... so when is it favorable to use a mutator vs. @property out of curiosity?
[04:17] <StevenK> wgrant: Re: your "What did it do before?" question, exactly that.
[04:17] <wgrant> Huh.
[04:17] <wgrant> I hadn't seen that before.
[04:17] <wgrant> OK.
[04:18] <lifeless> timrc: when clients through the API should do different things than clients inside the appserver.
[04:18] <StevenK> wgrant: It was inside notify()
[04:20] <StevenK> wgrant: I'd love to drop the hasattr() hack, too
[04:20] <StevenK> wgrant: But tests insist on passing in StringIO as the file_object
[04:25] <wgrant> StevenK: We should find some other way.
[04:25] <wgrant> StevenK: How was it done before?
[04:25] <wgrant> Did it use packageupload.changesfile.filename or something?
[04:25] <timrc> lifeless, okay. so if a mutator is used then clients within the appserver would basically need to call setPrivate explicitly rather then .private = boolean
[04:25] <timrc> lifeless, @property would give a common interface for both
[04:26] <StevenK> wgrant: It used packageupload.changesfile.filename
[04:26] <wgrant> StevenK: :( OK
[04:27] <wgrant> StevenK: We may want to rationalise this eventually.
[04:27] <wgrant> So we take a filename and either changesfile string or object... not all three.
[04:27] <StevenK> Mmmmm
[04:28] <StevenK> wgrant: Does http://pastebin.ubuntu.com/613578/ satisfy your "Can haz map?" comment?
[04:28] <wgrant> StevenK: It does indeed, but the location could be better.
[04:29]  * StevenK ponders lunch.
[04:30] <wgrant> StevenK: So, do you have any more ideas for merging the Confusing Four?
[04:30] <wgrant> send_mail can be pretty trivially folded into _sendNotification.
[04:30] <StevenK> I agree about that
[04:31] <StevenK> send_message() is also used by notify_spr_less's new name
[04:31] <wgrant> _sendNotification can be folded into notify()
[04:31] <wgrant> Right.
[04:31] <wgrant> StevenK: Hm, notify_spr_less doesn't want to use _sendMail?
[04:32] <StevenK> No, it's first argument is an apr
[04:32] <StevenK> *SPR
[04:32] <wgrant> It looks like it can be optional.
[04:32] <wgrant> It says 'if spr:'
[04:32] <wgrant> Indeed, it is optional.
[04:32] <wgrant> Use it if you can.
[04:33] <sinzui> wgrant: I did not see the fallout.
[04:33] <wgrant> Then send_message can be folded into there.
[04:33] <wgrant> sinzui: It hadn't been sending warnings.
[04:33] <wgrant> sinzui: So about 300 memberships expired without warning.
[04:33] <lifeless> timrc: right
[04:33] <wgrant> sinzui: But only 20ish were in restricted teams that they could have renewed themselves, and I think the owners have fixed those.
[04:33] <lifeless> mutators are basically fugly
[04:33] <sinzui> wgrant: :(
[04:33] <timrc> lifeless, aye
[04:34] <sinzui> I had answered a users question today saying all was fixed. He had noticed his membership was expiring and had not gotten an email
[04:35] <wgrant> lifeless: Let's rewrite Launchpad in Java.
[04:35] <lifeless> wgrant: indeed, why have one problem when we can have two!
[04:35] <timrc> wgrant, I think we should rewrite it in something more intuitive, like COW (http://www.bigzaphod.org/cow/)
[04:37] <wgrant> timrc: But one of the instructions is actually intuitive :(
[04:38] <StevenK> wgrant: The log level change is going to cause widespread changes to doctests
[04:39] <wgrant> StevenK: Indeed... We'll see how widespread it is.
[04:39] <wgrant> StevenK: If it's too hard, use a different log method for each, but still dedupe.
[05:28] <StevenK> wgrant: Changes made, and your branch merged.
[05:28] <StevenK> +16/-14 for nascent-announcements.txt
[05:28] <StevenK> Which is much less than I feared.
[05:32] <StevenK> wgrant: _sendNotification folded into notify()
[05:32] <LPCIBot> Project windmill-db-devel build #328: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-db-devel/328/
[05:35] <wgrant> StevenK: Hexcellent.
[05:37] <wgrant> Hmm, we haven't harrassed the LOSAs at all today :(
[05:37] <wgrant> We are not up to our usual standard.
[05:37]  * StevenK looks at merging send_mail() into notify()
[05:37] <wgrant> StevenK: Yay
[05:37] <wgrant> Er.
[05:37] <wgrant> No.
[05:38] <StevenK> Indeed, we call it twice
[05:38] <StevenK> [13:30] < wgrant> send_mail can be pretty trivially folded into _sendNotification.
[05:38] <StevenK> :-)
[05:39] <wgrant> StevenK: Oh, right, send_mail, not send_message.
[05:39] <wgrant> send_mail can be folded in.
[05:39] <wgrant> send_message should be merged into _sendMail, but that first requires that reject_changes_file use the latter instead.
[05:41] <StevenK> wgrant: However, we call send_mail twice -- once for annoucements and once for the message itself.
[05:42] <wgrant> StevenK: The args are the same except for action, recipients, from_addr and bcc_addr, AFAICT.
[05:42] <wgrant> Also, the subject can be shared, but the body cannot.
[05:43] <wgrant> Possibly reintroduce the do_send_mail closure.
[05:43] <wgrant> But at the end this time.
[05:43] <wgrant> Will save like 13 arguments and a confusing function name.
[05:53] <lifeless> poolie: you wanted to catch up more generally ?
[05:57] <StevenK> wgrant: notification.py |   18 ++----------------
[05:57] <StevenK> wgrant: From killing send_message
[05:58] <jtv> StevenK: I notice that DSDJob.run finds its DSD by {distroseries, sourcepackagename}.  Doesn't that become ambiguous with multi-parent?
[05:58] <StevenK> jtv: Yes, that should change.
[05:59] <StevenK> wgrant: Make that +2/-19
[05:59] <jtv> StevenK: do we have a bug/card for that?
[05:59] <StevenK> I can't recall off the top of my head
[06:00] <jtv> OK, I'll look.
[06:00] <wgrant> StevenK: :)
[06:00] <jtv> StevenK: bug 758906 may be a bit general
[06:00] <_mup_> Bug #758906: Allow a derived series to have multiple parents <derivation> <Launchpad itself:Triaged> < https://launchpad.net/bugs/758906 >
[06:00] <StevenK> AssertionError: Invalid recipient: '' in ['D', 'a', ...
[06:00]  * StevenK digs
[06:00] <wgrant> StevenK: Does that mean that send_mail and send_message are both dead?
[06:01] <StevenK> send_mail is not, send_message is
[06:01] <wgrant> I am disappoint.
[06:01] <StevenK> Of course you are.
[06:02] <wgrant> I'm hoping that notification.py drops below 500 lines.
[06:02] <poolie> hi lifeless
[06:03] <lifeless> o/ poolie
[06:03] <StevenK> wgrant: 509
[06:03] <poolie> sure
[06:03] <poolie> now if you like
[06:03] <wgrant> StevenK: Victory is near.
[06:03] <lifeless> poolie: that would be great. shall we try skype?
[06:04] <StevenK> wgrant: What was your plan to kill send_mail?
[06:09] <wgrant> StevenK: Give me a sec.
[06:14] <StevenK> wgrant: My branch has also fallen behind Full HD
[06:16] <wgrant> StevenK: Hm, I have an odd failure in distroseriesqueue-notify.txt.
[06:16] <wgrant> Have you fixed that one yet?
[06:16] <StevenK> I've not been running the soyuz tests
[06:19] <wgrant> r13104 broke it.
[06:19] <StevenK> :-(
[06:20] <StevenK> Ah, that could be the DEBUG vs INFO
[06:20] <wgrant> Hm, possibly.
[06:20] <wgrant> Doesn't look like it, though.
[06:20] <StevenK> I'll dig when archiveuploader stops running
[06:21] <wgrant> Also, just found a bug in r13104
[06:21] <wgrant> -    for bpr in bprs:
[06:21] <wgrant> -        names.add(bpr.build.source_package_release.name)
[06:21] <wgrant> -        version = bpr.build.source_package_release.version
[06:21] <wgrant> +    elif bprs:
[06:21] <wgrant> +        names.add(bpr[0].build.source_package_release.name)
[06:21] <wgrant> +        version = bpr[0].build.source_package_release.version
[06:21] <wgrant> You need to add the names even if there are sprs.
[06:21] <wgrant> Just not the version.
[06:22] <wgrant> Oh.
[06:22] <wgrant> Heh.
[06:22] <wgrant> It was the DEBUG/INFO change: the unification added some new fields.
[06:22] <StevenK> Ah
[06:22] <StevenK> Sorry, I fixed that locally
[06:23] <StevenK> In r13105
[06:23] <wgrant> Great.
[06:23] <StevenK> Do you have a diff for the -notify change?
[06:23] <wgrant> Just pushing.
[06:23] <StevenK> Or have you not fixed it?
[06:24] <wgrant> Oh.
[06:24] <wgrant> No, that one I haven't fixed.
[06:24] <wgrant> There will be many more like it.
[06:24] <wgrant> I'm pushing the send_mail merge.
[06:24] <wgrant> Done.
[06:24] <StevenK> I've just pushed r13107
[06:24] <wgrant> Hm.
[06:25] <wgrant> Have you?
[06:25] <StevenK> Pushing
[06:25] <StevenK> When that returns, I'll re-merge your branch
[06:25] <StevenK> Hm. No progress either
[06:26] <StevenK> connect(4, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("<IP_ADDRESS>")}, 16
[06:26] <StevenK> Odd
[06:30] <StevenK> ssh: connect to host bazaar.launchpad.net port 22: Connection timed out
[06:30] <StevenK> Hmmm
[06:31] <StevenK> But ssh -vv connects
[06:31] <wgrant> WFM :(
[06:31] <StevenK> So I'm confused
[06:31] <StevenK> Ah, there it goes
[06:31] <StevenK> wgrant: Sorry, pushed.
[06:34]  * StevenK attempts to merge in wgrant's latest branch, dies from conflicts
[06:34] <wgrant> :(
[06:34] <StevenK> wgrant: I can't make sense of them either
[06:34] <wgrant> Oh?
[06:34] <wgrant> Let me see.
[06:34] <wgrant> zomg conflicts
[06:35] <wgrant> Oh.
[06:35] <wgrant> You demolished _sendNotification.
[06:35] <wgrant> I see.
[06:36] <StevenK> You said to? :-)(
[06:36] <StevenK> s/(//
[06:41] <wgrant> StevenK: Pushed. You should just be able to pull.
[06:41] <wgrant> 497 lines.
[06:42] <StevenK> \o/
[06:44]  * StevenK looks at distroseriesqueue
[06:45] <wgrant> StevenK: Can you also fix bcc_addr calculation?
[06:45] <wgrant> StevenK: It should use the spr name and then fall back to the first bpr name.
[06:45] <wgrant> StevenK: And not duplicate the template.
[06:47] <StevenK> wgrant: http://pastebin.ubuntu.com/613612/
[06:48] <wgrant> StevenK: elif bprs
[06:53] <wgrant> StevenK: I'm still not quite sure how notification.py has ended up 20% shorter, despite some stuff being moved into it from queue.py...
[06:53] <StevenK> Haha
[06:53] <StevenK> Iz bonus
[06:54] <StevenK> wgrant: Fixed distroseriesqueue*
[06:55] <wgrant> StevenK: I would avoid further elision like the nascentupload-announcements.txt fix.
[06:55] <wgrant> It may conceal unexpected Bcc and From additions.
[06:55] <StevenK> :-(
[06:56] <StevenK> How did you know that's how I fixed them?
[06:56] <wgrant> Heh
[06:56] <wgrant> I was actually typing that before you said you'd fixed them :(
[06:56] <StevenK> Oh, so since I've done it, I can leave it? :_)
[06:57] <wgrant> No.
[06:58] <StevenK> Should I fix nascentupload-announcements.txt as well?
[06:58] <wgrant> StevenK: Ideally.
[06:58] <lifeless> cody-somerville: your bug is fixed; will be deployed monday
[07:03] <StevenK> % psql -l | egrep -c 'ftest_[0-9]'
[07:03] <StevenK> 8
[07:03] <StevenK> With no test suite running :-/
[07:08] <StevenK> wgrant: distroseriesqueue* fixed properly
[07:08] <wgrant> Great.
[07:08] <wgrant> I think this is just about done.
[07:09] <StevenK> The only thing I can think of is the hasattr() hack
[07:09] <wgrant> Yes.
[07:09] <wgrant> That's only used by notify(), right?
[07:10] <wgrant> An extra arg at that single level won't hurt too much.
[07:10] <StevenK> No, reject_changes_file
[07:10] <wgrant> Well, yes, but that's called immediately by notify()
[07:10] <wgrant> So it doesn't affect the majority of the code.
[07:11] <StevenK> Bah, I called it reject_changes_file*s* ?
[07:11] <wgrant> :( fixit
[07:11] <StevenK> Fixed
[07:17] <StevenK> wgrant: r13111 pushing
[07:18] <StevenK> Hmm, it's back over Full HD again.
[07:21] <StevenK> wgrant: Diff in the MP has updated, once more with feeling?
[07:28] <wgrant> StevenK: Soyuz tests are passing?
[07:29] <StevenK> Still running archivepublisher
[07:29] <StevenK> But I can let you know in 30 minutes :-(
[07:30] <wgrant> So, I'll rereview in a sec.
[07:30] <StevenK> wgrant: Running soyuz now, no failures in archivepublisher
[07:30] <wgrant> What are your next steps?
[07:30] <wgrant> After this branch?
[07:31] <StevenK> I was going to say hook this into the package copier, but that is dangerous
[07:31] <wgrant> It might be worth seeing how hard it is to extract reject_changes_file() from notify(), making archiveuploader call it directly.
[07:31] <wgrant> But if you want to go directly to the copier goal, you'll need to wean notify() and co. off the changesfile.
[07:31] <StevenK> I tried that, archiveuploader deals with both forms of rejection in one method
[07:31] <wgrant> Stop using it for Changed-By and Maintainer, for example.
[07:31] <wgrant> Bah.
[07:31] <wgrant> That's stupid.
[07:32] <wgrant> But OK.
[07:32] <StevenK> My concern with the package copier calling it is that notify() is fairly heavyweight, and the package copier needs to be lean and fast
[07:33] <wgrant> Does it?
[07:33] <StevenK> Otherwise copying times out and people yell at me. :-(
[07:33] <wgrant> These copies won't be done inline.
[07:33] <StevenK> Ahh
[07:34] <wgrant> Well, for security copies they probably will for the short-term.
[07:34] <StevenK> So call notify() in PCJ, *not* do_copy
[07:34] <wgrant> But this is pretty light-weight...
[07:34] <wgrant> No, do_copy.
[07:34] <wgrant> But only security copies and PCJ will use it for now.
[07:34] <StevenK> That's fairly easy guarded
[07:34] <persia> On a vaguely related note, did the job to pro[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[Ccess all the old copyright files ever run?
[07:34] <wgrant> No need.
[07:34] <wgrant> The other types of copies are unsupported.
[07:35] <wgrant> persia: Old changelog files? Yes.
[07:35] <persia> Oh, excellent
[07:35] <StevenK> persia: It took one month to run
[07:35] <StevenK> persia: And processed roughly 580,000 SPRs.
[07:35] <wgrant> Only 'cause you threw away my good one :P
[07:35] <persia> StevenK: It took about one year to schedule, so I'm happy with the run time :)
[07:35] <StevenK> So we thanked it by deleting it from the codebase.
[07:35] <StevenK> wgrant: I got lifeless'd
[07:36] <StevenK> wgrant: And I didn't throw it away, it mutated ...
[07:36] <StevenK> wgrant: Uh? What about ppa-to-ppa copies?
[07:36] <wgrant> StevenK: They shouldn't announce.
[07:37] <wgrant> We will handle that in the integration.
[07:37] <StevenK> Clearly
[07:37] <wgrant> But it should be handled with the rest of the do-not-announce logic.
[07:37] <wgrant> Not by not calling notify().
[07:37] <StevenK> Right
[07:37] <StevenK> wgrant: Are you reviewing, or waiting for soyuz test results?
[07:38] <StevenK> Or doing something else entirely :-)
[07:38] <wgrant> Will look shortly.
[08:07] <StevenK> wgrant: 2 failures in soyzu
[08:07] <StevenK> *soyuz
[08:07] <StevenK> They're both doctests, so I guess it's more INFO vs DEBUG fallout
[08:22] <wgrant> StevenK: Have you disposed of _filename yet?
[08:24] <StevenK> wgrant: Yes
[08:24] <StevenK> Trying to work out the xx-queue-pages.txt failure
[08:24] <StevenK> soyuz-set-of-uploads failed due to INFO vs DEBUG
[08:26] <wgrant> The rejection message seems to be None.
[08:26] <StevenK> Yes, I think I've found the bug.
[08:27] <StevenK> And found a stray place _filename hasn't been erricated yet
[08:31] <StevenK> wgrant: r13112 pushed.
[08:32] <StevenK> wgrant: Did you notice my drive-by to drop pocketsuffix from queue?
[08:32] <wgrant> StevenK: I WTF'd at it for a minute and then worked out it was a drive-by, yes.
[08:32] <wgrant> *Not* really the right sort of branch for drive-bys, but I won't hurt you too much.
[08:33] <StevenK> Well, true, it's large and hurty enought
[08:33] <StevenK> s/t$//
[08:34] <StevenK> wgrant: Diff updated.
[08:40] <wgrant> StevenK: The summarystring stuff could do with a shuffle.
[08:40] <StevenK> wgrant: Er, which bit?
[08:40] <wgrant> I'd move the buildSummary bit (line 144) into an else block after the "if action == 'rejected'"
[08:40] <wgrant> Since the rejected bit clobbers it.
[08:42] <StevenK> wgrant: Done
[08:51] <wgrant> StevenK: Could you also de-underscore and de-CamelCase the remaining functions?
[08:51] <wgrant> Apart from that I think it is pretty much landable.
[08:51] <wgrant> We will see Julian scream in a few minutes, I guess?
[08:56] <mrevell> How do?
[08:59] <StevenK> wgrant: Does mean you're willing to Approve it?
[09:00] <StevenK> s/s m/s that m/
[09:01] <jml> huwshimi: hi
[09:01] <huwshimi> jml: Hello!
[09:02] <StevenK> wgrant: r13113 pushed.
[09:02] <jml> huwshimi: let's talk :)
[09:02] <huwshimi> jml: Skype?
[09:05] <StevenK> wallyworld_: Are you still the OCR?
[09:05] <wallyworld_> StevenK: perhaps not anymore
[09:05] <wallyworld_> i should change the topic
[09:05]  * wallyworld_ is about to eat dinner
[09:06] <StevenK> I wonder if that 209 count is still right
[09:07] <wgrant> It's 210 now, I think.
[09:07] <wgrant> Possibly more.
[09:07] <wallyworld_> it seems to be stuck around 200 :-(
[09:07] <wgrant> It's decreasing.
[09:07] <wgrant> But then stuff gets escalated.
[09:08] <wallyworld_> right
[09:08] <wgrant> http://webnumbr.com/launchpad-critical-bugs
[09:08] <wallyworld_> nice graph. i hadn't seen that before
[09:10] <wgrant> There are 9 escalated bugs.
[09:10] <StevenK> wgrant: The diff has updated, can haz comment/approve?
[09:11] <wgrant> bigjools must be subjected to it first.
[09:11] <StevenK> bigjools: https://code.launchpad.net/~stevenk/launchpad/refactor-notification/+merge/61919
[09:12] <bigjools> bzr repacking a commit when you just want to push before your battery runs out is sub optimal
[09:12] <bigjools> hey wallyworld_ you're up late
[09:12] <adeuring> goodmorning
[09:13] <wgrant> The notification.py diff is pretty much useless, but the new file is short and pretty readable.
[09:13] <wgrant> And self-contained.
[09:19] <lifeless>  http://webnumbr.com/.join(launchpad-oops-bugs.all,launchpad-timeout-bugs.all,launchpad-critical-bugs.all)
[09:24] <jtv> Who's up for a review?  https://code.launchpad.net/~jtv/launchpad/db-bug-788526/+merge/62623
[09:33] <adeuring> jtv: I'll look
[09:34] <jtv> thanks adeuring
[09:36] <LPCIBot> Project windmill-db-devel build #329: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-db-devel/329/
[09:41] <StevenK> Dear Unity, why are you making my laptop screen flicker?
[09:48] <danilos> StevenK: it's not Unity, it's me!
[09:48] <StevenK> danilos: How are you doing that, then? :-)
[09:49] <danilos> StevenK: just saying I might drop by and then it shudders (manifests as flicker ;))
[10:26] <StevenK> wgrant: bigjools has approved, your turn
[10:32] <adeuring> jtv: r=me
[10:32] <jtv> thanks!
[10:33] <jml> Food time!!#@@!#
[10:33] <jml> (I'm pretty excited about it)
[10:35] <wgrant> StevenK: It is done.
[10:36] <bigjools> wgrant: I'm sad that you're not on maintenance rotation any more, I was going to press-gang you into fixing the FatalUploadError-generating-an-oops-for-bad-gpg-signatures annoyance
[10:37] <bigjools> since every single soyuz oops for the last few days has been those
[10:37] <wgrant> bigjools: As I said, I was looking at that last week, but got distracted by the whole epic failure thing.
[10:37] <wgrant> Yeah.
[10:37] <wgrant> The missing mandatory field errors are now replaced by those.
[10:37] <wgrant> Since it does signature verification first.
[10:37] <StevenK> wgrant: bigjools wished for docstrings, so 527
[10:37] <wgrant> bigjools is a terrible person.
[10:37] <wgrant> But probably correct.
[10:37] <StevenK> Haha
[10:38]  * bigjools is merely enforcing the existing rules ;)
[10:38] <wgrant> At least we removed a few functions that would have also needed 15-20 line docstrings.
[10:39] <bigjools> yarp
[10:39] <wgrant> I'm sure I can refactor some more out of it, but this is workable, landable, somewhat reviewable, and makes me cry less.
[10:40] <lifeless> gpghandler-service ftw
[10:40] <wgrant> Yes
[10:40] <wgrant> Hopefully first thing.
[10:40] <lifeless> wgrant: have you seen https://dev.launchpad.net/ArchitectureGuide/ServicesRequirements ?
[10:40] <wgrant> I have.
[10:40] <lifeless> good ;)
[10:41] <wgrant> But it's 10pm on your Friday night, so you are not here.
[10:41] <lifeless> I am writing up a mail to the list even now
[10:41] <lifeless> I have a cat nestled in the crook of my legs, wife on the couch beside me and tv on
[10:41] <wgrant> Seeing KPI used in a technical document makes me cringe, but I will survive.
[10:46] <LPCIBot> Project windmill-devel build #145: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/145/
[10:47] <jml> actually, still no food, and I have to run an errand.
[10:47] <jml> back soon.
[11:23] <jml> back
[11:34] <adeuring> is anybody aroubd with Twisted-fu? I'm trying to let the test-keyserver return a 500 error when a non-existing key is looked up. (That's what our real-life keyserver does, really)
[11:35] <wgrant> A 500?
[11:35] <wgrant> That would be an SKS bug.
[11:35] <adeuring> Using ErroPage() seems to work, but how can I test this?
[11:35] <adeuring> wgrant: yes, it is -- but should we fix this too?
[11:36] <adeuring> wgrant: just try http://keyserver.ubuntu.com:11371/pks/lookup?search=0x6F0DAED1&op=vindex
[11:40] <adeuring> wgrant: but anyway, even if it would return a 404: My question is: How can I test that our test keyserver returns a 404 or 500 or whatever other error?
[11:41] <wgrant> Nobody has done anything significant to zeca in quite a while... I'm not sure if it's tested.
[11:41]  * wgrant looks around.
[11:42] <wgrant> Oh, the tests aren't too bad.
[11:42] <wgrant> adeuring: So you're not sure how to assert an HTTP error in test_web?
[11:43] <adeuring> wgrant: right
[11:43] <adeuring> wgrant: Returning ErrorPage(...) in web.py _seems_ to work, bt I'd like to test that properly...
[11:45] <wgrant> adeuring: I presume twisted.web.client.getPage calls the errback if an error occurs.
[11:45] <wgrant> Yeah: "Download a page. Return a deferred, which will callback with a page (as a string) or errback with a description of the error."
[11:45] <adeuring> wgrant: I have no real clue about twisted... So I would have to add an error callback?
[11:46] <wgrant> adeuring: getPage returns a Deferred, to which you can addCallback and addErrback.
[11:46] <wgrant> adeuring: You'll see it currently uses addCallback to add an assertion.
[11:46] <wgrant> On the success case.
[11:46] <adeuring> wgrant: ah, right! thanks!
[11:52] <spiv> adeuring: twisted.trial.unittest.TestCase has an assertFailure method that may help: http://twistedmatrix.com/documents/current/api/twisted.trial.unittest._Assertions.html#failUnlessFailure
[11:52] <adeuring> spiv: thanks!
[11:53] <spiv> adeuring: (despite the API doc link, the preferred name for that method is assertFailure not failUnlessFailure)
[11:54] <spiv> adeuring: the basic trick to know is that trial's TestCase allow you to return a Deferred from your test method (and setUp etc), and the test will wait for the result/failure of that before completing.
[11:54] <adeuring> spiv: ok
[11:54] <jml> spiv: actually, most of our Twisted tests don't use trial TestCase
[11:55] <spiv> jml: *shudder*
[11:55] <jml> spiv: no, it's actually awesome
[11:55] <spiv> jml: awesome can make a person shudder too!
[11:55] <jml> spiv: 'run_tests_with = AsynchronousDeferredRunTest'
[11:55] <spiv> jml: the interface for test writers is approximately the same?
[11:56] <jml> spiv: yeah. things like the assert you mentioned are free-floating functions
[11:56] <jml> spiv: and it's more strict with reactor cleanup
[11:56] <jml> (and there's more helpers for debugging)
[11:56] <jml> (and you need to do less multiple inheritance)
[11:57] <spiv> jml: \o/
[11:57] <jml> spiv: http://readthedocs.org/docs/testtools/en/latest/for-test-authors.html#twisted-support
[12:44]  * henninge lunches
[13:26] <bac> hello adeuring.  busy today?
[13:26] <adeuring> bac: not really
[13:34] <henninge> Hi! I have re-installed my laptop and used rocketfuel-setup to get my LP setup going again. I also had saved my homedir and copied it back to the new installation, so I may have mixed stuff.
[13:34] <henninge> Now make schema won't work, it breaks off like this: http://paste.ubuntu.com/613727/
[13:35] <henninge> The last line is about "ident authentification failing for user henning"
[13:35] <henninge> What's missing?
[13:39] <henninge> Would rocketfuel-setup not create a user for my account?
[13:39] <StevenK> rf-setup does not run utilities/launchpad-database-setup
[13:40] <henninge> oh
[13:40] <StevenK> henninge: "utilities/launchpad-database-setup $(whoami)"
[13:40]  * henninge should have read that again
[13:40] <henninge> StevenK: thanks!
[13:41] <StevenK> I may be wrong, the rf-setup code makes me sob.
[13:42] <henninge> no, it's coming back to me that we split that back when we open sourced because people did not like rf to mess with their database.
[13:42] <StevenK> Well, truth be told, rf-setup is not something to be run often
[13:42] <henninge> exactly
[13:43] <henninge> make schema is doing what it should now. ;-)
[13:43] <henninge> now henninge can run tests ...
[13:45]  * StevenK high fives henninge
[13:45] <henninge> ;-)
[14:13] <bac> hi sinzui, gary says you brought up bug 186660 to him recently as something we might look at soon.  it would possibly close several bugs but none are marked critical.
[14:13] <_mup_> Bug #186660: Launchpad shouldn't store wiki names <lp-registry> <users> <Launchpad itself:Triaged> < https://launchpad.net/bugs/186660 >
[14:14] <sinzui> bac: That is right. We have ignored the issue for many years. I was just noting that with the SSO change last year. We might be able to close all wikiname bugs except the one saying it should be removed
[14:15] <jtv> allenap: you've got a test here called test_requestUpgrade_is_efficient.  It seems to assert that the query count does not increase with the number of jobs it needs to create.  I'm not so sure Storm will let us do that.
[14:24] <jtv> bac: I've got an oversized and tedious MP here, and I have to leave.  But _if_ you have no problem with that, then I'd be grateful if you could review!  https://code.launchpad.net/~jtv/launchpad/db-bug-788956/+merge/62669
[14:24] <bac> jtv: you're a natural-born salesman
[14:24] <jtv> Yuck.
[14:24] <jtv> I've done sales, but I'm only good at it if I believe in what I sell.
[14:24] <bac> who could pass oversized, tedious, and unattended?
[14:25] <jtv> You could if you wanted to!
[14:25] <bac> jtv: i'll have look in a bit
[14:25] <jtv> Great, thanks
[14:40] <jtv> Have a good weekend, everyone!
[15:13] <allenap> gmb: Do I get extra karma for getting two [r=allenap]s into a commit message? ;)
[15:14] <gmb> allenap: Sadly not :).
[15:15] <gmb> Hahah. "Strongly suggest you use lp-land." I did and it added the extra tags. Unhelpful.
[15:16] <sinzui> jcsackett: so you have time to talk?
[15:16] <jcsackett> sinzui: sure. mumble or sip?
[15:17] <sinzui> sip?
[15:18] <sinzui> We miss connected
[15:18] <jcsackett> we did. :-P
[15:42] <LPCIBot> Project windmill-db-devel build #330: STILL FAILING in 1 hr 12 min: https://lpci.wedontsleep.org/job/windmill-db-devel/330/
[16:34] <abentley> adeuring or bac: could you please review https://code.launchpad.net/~abentley/launchpad/duplicate-msgid/+merge/62697 ?
[16:34] <adeuring> abentley: sure
[16:34] <abentley> adeuring: thanks.
[16:53] <adeuring> abentley: r=me
[16:53] <abentley> adeuring: thanks.
[16:55] <LPCIBot> Project windmill-devel build #146: STILL FAILING in 1 hr 13 min: https://lpci.wedontsleep.org/job/windmill-devel/146/
[17:11] <LPCIBot> Project windmill-db-devel build #331: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/331/
[17:11] <abentley> bac: does OOPS-1963SMS24 make any sense to you?  It's apparently the cause of bug #784008.
[17:11] <_mup_> Bug #784008: problem when pushing fix for a fix-committed bug <branch-scanner> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/784008 >
[17:12]  * bac looks
[17:17] <gmb> adeuring, bac : Could one of you take a look at https://code.launchpad.net/~gmb/launchpad/choose-affected-product-oops-bug-370117/+merge/62704 for me?
[17:17] <bac> gmb: i will
[17:17] <gmb> bac: Thankee
[17:21] <bac> abentley: the OOPS does not make sense to me b/c the code it references no longer exists.
[17:22] <abentley> bac: Thanks.  I guess the bug probably is fixed, too, but I'll poke at that later.
[17:22] <bac> abentley: i hope so...
[17:23] <bac> gmb: short, sweet, r=bac
[17:23] <gmb> bac: Ta.
[17:24] <abentley> bac: I have trouble seeing why the bug and the oops would be connected, so it's possible another issue was at play for the oops, and the bug still exists.
[18:25] <nigelb> Hi, I just filed bug 789222, which I introduced with my "fixes"
[18:25] <_mup_> Bug #789222: Sprints and specification subscribers are really not alphabetically sorted <Launchpad itself:New> < https://launchpad.net/bugs/789222 >
[18:25] <nigelb> should I be separating the sprints and specification into separate branches and bugs or together is fine?
[18:25] <nigelb> I know the fix for it and I'm working on it.
[18:29] <jml> nigelb: if the branch gets too complex to think about or review, then you'll know you should have split it.
[18:29] <jml> nigelb: but probably it's ok to do them together.
[18:29] <nigelb> jml: Its basically just a small change of one lines each, unless you insist on writing new test cases to catch that.
[18:30] <jml> nigelb: well, if you introduced a bug with your fixes, it shows that we don't have enough tests for this area
[18:30] <jml> nigelb: so, yes I will insist :)
[18:34] <nigelb> jml: heh :D
[18:34] <nigelb> I knew you'd insist :D
[18:34] <nigelb> jml: I don't know if I want to touch the doctests for the specifications.
[18:35] <jml> nigelb: give it a try at least.
[18:36] <nigelb> I'm tempted to just write new unit tests.
[18:36] <nigelb> Wait, that's a trap. I'll end up writing a whole bunch of unit tests.  I take that back :p
[18:38] <jml> nigelb: you'll need some kind of test. do which ever is easier for you.
[18:38] <nigelb> jml: :)
[18:38] <nigelb> Sorry for this sort of mess I caused :)
[18:40] <jml> np.
[18:42] <nigelb> jml: When is the sprint in Dublin?
[18:43] <nigelb> I guess the pie on the face is less likely now :(
[18:43] <jml> nigelb: June 27th: 1 month
[18:43] <jml> nigelb: yes, quite unlikely.
[18:43] <jml> nigelb: but still possible.
[18:44] <nigelb> heh
[18:46]  * jml is off
[18:46] <jml> g'night all
[18:46] <jml> see you in a bit over a week's time.
[18:48] <nigelb> ouch, I messed up postgres :(
[18:48] <nigelb> apparently, at some point I accidentally uninstalled it
[18:48] <nigelb> I ran rocketful-setup again, but that didn't get the schema on there
[18:49] <nigelb> how do I fix that?
[18:50] <nigelb> nvm, I think I fixed it.
[19:06] <nigelb> No I didn't, sigh.
[19:50] <LPCIBot> Project windmill-db-devel build #332: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-db-devel/332/
[19:55] <flacoste> anyone knows how to make a source package branch the official one?
[20:02] <LPCIBot> Project windmill-devel build #147: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/147/
[20:17] <nigelb> bac: I'm picking that task up. Just that I broke my local dev set up and trying to figure out if I have to reinstall the whole thing.
[20:18] <flacoste> bug 347770
[20:18] <_mup_> Bug #347770: UI for making a branch an official package branch <lp-code> <package-branches> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/347770 >
[20:18] <bac> nigelb: great to hear, except for the borked machine
[20:19] <nigelb> Note to self: reinstalling rabbitmq was a bad idea.
[20:19] <flacoste> james_w: is there an existing tool that uses the API to set official package branches? (is it done as part of package-importer?) or should I write my own (i want to set official package branches on another distribution)
[20:19] <james_w> flacoste, there's set_official.py in lp:udd I think
[20:31] <flacoste> james_w: i'll have a look
[21:09] <LPCIBot> Project windmill-db-devel build #333: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-db-devel/333/
[21:15] <poolie> has anyone seen this error from ec2:
[21:15] <poolie> AttributeError: 'Entry' object has no attribute 'queue_status'
[21:15] <poolie> what a silly error too
[21:37] <abentley> poolie: it sounds like ec2 was expecting a merge proposal but got something else.
[21:39] <poolie> yes
[21:40] <poolie> i gave it a branch
[21:40] <poolie> perhaps i'll shave that restfulclient yak
[22:17] <LPCIBot> Project windmill-devel build #148: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/148/
[22:25] <nigelb> anyone around to review a branch?
[22:26] <nigelb> poolie: You around?
[22:27] <nigelb> I'm headed to bed. If someone can review https://code.launchpad.net/~nigelbabu/launchpad/789222-sort-fix/+merge/62739 that'd be awesome :)
[22:40] <poolie> hi nigelb
[22:57] <poolie> replied
[23:00] <LPCIBot> Project windmill-db-devel build #334: STILL FAILING in 43 min: https://lpci.wedontsleep.org/job/windmill-db-devel/334/
[23:06] <lifeless> *stretch*
[23:06] <poolie> hi there
[23:06] <lifeless> flacoste: there is an API call I believe. No web UI atm.
[23:09] <flacoste> lifeless: yep
[23:09] <lifeless> I see the futher discussion now ;)
[23:23] <poolie> lifeless: if you're in lp mode, can you tell me if there's a better way to write https://code.launchpad.net/~nigelbabu/launchpad/789222-sort-fix/+merge/62739
[23:27] <poolie> tx
[23:28] <lifeless> no probs


[10:28] <pavlushka> Good day Kilos :)
[10:28] <Kilos> hi pavlushka
[10:31] <pavlushka> How are you Kilos :)
[10:36] <Kilos> im ok ty and you? i just get as much sun and heat as possible in winter.
[13:56] <pavlushka> Kilos: yep, make sure that :)
[20:28] <pavlushka> good night zaki :p
[20:33] <zaki> good night pavel vai :)


[15:45] <luna>  and Phoronix and Distrowatch being early again as always :P
[15:47] <luna> writing Ubuntu 23.04 and flavours is released just becouse its at the Canonical London datacenter, that are still mirroring the file out for another 2,5-3,5 hours but when people download the file from the London DC that does the mirroring job it slows down the actual release and make it take 6-9 hours or 9-13 hours instead of 3 hours total always happends
[15:48] <luna> its nice when the Linux news sites slows down the mirroring process (and it always happens)
[16:04] <ravage> the links are already on ubuntu.com so nobody should be surprised about downloads at this point
[16:06] <luna> ravage: yeah but was not when i posted but now they are, are those okay to use?
[16:06] <ravage> im sure you will not break the infrastructure with your download
[16:07] <ravage> torrents are always the nicer way of course
[16:13] <luna> downloading with QBitorrent seems to work better then KTorrent and only takes 2 hours instead of 2 days now
[16:13] <Berge> HTTP downloads should be fine
[16:13] <Berge> luna: Where are you at?
[16:14] <luna> Berge: Sweden, Stockholm
[16:14] <Berge> luna: http://se.releases.ubuntu.com/23.04/ should be plenty fast for you
[16:14] <Berge> oh, wait, it's not ACC right now?
[16:14] <Berge> Try http://no.releases.ubuntu.com/23.04/
[16:15] <luna> Berge: still being mirrored so got told to use the torrent
[16:15] <Berge> luna: I run no.releases.ubuntu.com, and it should be up to date
[16:16] <luna> oh o
[16:16] <luna> ok
[16:16] <luna> https://i.imgur.com/QWDDl8t.png
[16:16] <luna> torrent får duga ;)
[16:16] <luna> men takk ändå
[16:16] <Berge> yeah, just curious
[16:17] <Berge> Is 2.4 MiB/s saturating your bandwidth?
[16:17] <Berge> maswan: https://www.accum.se/help/faq/index.html.en#acc.umu.se oh wow
[16:18] <luna> Berge: well its my wifi on an old laptop running Slackware my desktop is most likely better connected to the internet but having migrane and headaches so laying in bed and not in a rush
[16:18] <Berge> luna: ouch, feel better soon!
[16:18] <Berge> maswan: I should probably update my ftp.acc.umu.se-references around
[16:38] <maswan> Berge: mirror.accum.se is the new canonical name, but there's not a big urgency on that part. the emails on the other hand are already gone.
[16:38] <maswan> oh, I wonder why se isn't pointed at us at the moment
[16:48] <luna> and bam Ubuntu 23.04 is offically out: https://lists.ubuntu.com/archives/ubuntu-announce/2023-April/000289.html
[17:05] <luna> flashing it on the Ubuntu USB stick i got from Philipp Kewisch at this years FOSDEM now
[17:18] <luna>  there we go now we have Ubuntu 23.04 :)
[17:18] <Berge> maswan: Such a weird move from UMU
[17:19] <Berge> Espeically for such an institution as the ACC
[20:49] <maswan> Berge: I've gotten "wow, UmU is such a cool place compared to KTH, for all the services run under acc.umu.se"
[20:49] <maswan> Berge: from a postdoc at KTH for instance
[20:49] <maswan> anyway, the mirror name will be around for several years to come, probably 5-10


[13:01] <shahan> how to check my processor bit? whether it is 32 or 64 bit?
[13:03] <s-fox> Hello.
[13:04] <Guest55045> how to check my processor bit? whether it is 32 or 64 bit?
[13:05] <holstein> Guest55045: you can open a terminal and run...
[13:05] <holstein> uname -m
[13:06] <Guest55045> holstein: its returns i686
[13:06] <Guest55045> holstein: what does it mean?
[13:06] <holstein> 32bit
[13:07] <Guest55045> holstein: hmm.. tnx
[13:07] <holstein> also
[13:07] <holstein> file /sbin/init
[13:07] <Guest55045> holstein: I got a web link.  https://help.ubuntu.com/community/32bit_and_64bit
[13:07] <Guest55045> holstein: check this instead of the previous https://help.ubuntu.com/community/32bit_and_64bit#How_to_Check
[13:08] <holstein> Guest55045: sure... im getting these commands from searching 'ubuntu 32 or 64 bit how to tell'
[13:08] <Guest55045> it says http://paste.ubuntu.com/717813/
[13:09] <holstein> theres also http://www.cyberciti.biz/faq/linux-how-to-find-if-processor-is-64-bit-or-not/
[13:09] <holstein> AFAIK, what we are looking at is *if* you have 32 or 64 installed
[13:09] <holstein> but, is your proc 64bit capable?... if thats the question, you might want to look at that
[13:10] <Guest55045> holstein: ya.. I want to know about my processor's capability
[13:10] <Guest55045> whether it support 64 or not
[13:10] <holstein> right
[13:11] <Guest55045> holstein: but the output I dont understand
[13:11] <holstein> well, you look for lm's
[13:11] <holstein> as per the link "lm flag means Long mode cpu - 64 bit CPU"
[13:12] <Guest55045> then what does it mean for me?
[13:12] <Guest55045> holstein: Is it supporting the 64?
[13:12] <holstein> Guest55045: it means... if you have lm's in that file, you have "long mode" CPU which = 64bit
[13:12] <holstein> do you see lm's in that file?
[13:13] <Guest55045> http://paste.ubuntu.com/717813/
[13:13] <Guest55045> here is my output
[13:13] <holstein> sure
[13:13] <holstein> Guest55045: ive looked
[13:13] <holstein> have you?
[13:13] <Guest55045> hmm
[13:13] <Guest55045> lm
[13:13] <Guest55045> that means it support 64
[13:14] <holstein> Guest55045: from the site where you got that command
[13:14] <holstein> "lm flag means Long mode cpu - 64 bit CPU"
[13:14] <Guest55045> ya...
[13:14] <Guest55045> thank you very much :)
[13:14] <Guest55045> take care
[13:15] <holstein> o/
[16:45] <nijad> can someone help me on  giving write access to a db
[21:27] <three18ti> how do I differentiate public vs private networks when using multiple nics?
[21:32] <three18ti> To put the question into context, I am building a cluster, and would like to have eth0 connected to the Internet and eth1 connected to the node head.
[21:33] <three18ti> intermittently I am not receiving a ping response to pinging a public domain, however, ping does resolve the IP.
[21:34] <holstein> hmmm... that would be a DNS record though right?
[21:35] <holstein> not necessarily indicative of connectivity
[21:35] <holstein> mabye im wrong
[21:35] <holstein> three18ti: what are you trying to do?
[21:35] <three18ti> connect a machine to a public and private network.
[21:36] <holstein> with 2 different NICs
[21:36] <three18ti> yes.
[21:36] <three18ti> they are effectively separate networks.
[21:38] <holstein> http://itknowledgeexchange.techtarget.com/itanswers/multiple-network-cards-config/
[21:38] <holstein> ^^ thats what i would expect in a GUI
[21:38] <holstein> just selecting each one, and configuring based on what each network is expecting
[21:39] <three18ti> ubuntu server.  but I'm comfortable editing the config.
[21:40] <holstein> with a headless box i would think it would be a matter of manually configuring /etc/network/interfaces
[21:40] <three18ti> so riddle me this, they are both DHCP networks, could this be my issue?
[21:40] <holstein> shouldnt matter right?
[21:40] <holstein> either way, you can static IP on both outside the DHCP range to test
[21:41] <holstein> i wouldnt be ashamed of using a live CD to set it up once in the GUI, and test, and poke around to learn how to do it in the terminal on the server
[21:45] <three18ti> ok, maybe the issue is self inflicted...
[21:46] <three18ti> I was trying to cheat and use the already existing virtual bridge, virbr0, which I think VirtualBox created when I had to use it months ago...
[21:47] <three18ti> I think I left out the part about how this is a virtual cluster and I'm using qemu on dev machine.
[21:48] <three18ti> maybe VBox does something hinkey when it configures the interface?...
[21:50] <holstein> not that im aware of
[21:50] <three18ti> ha! just turned up another machine using two nics and I can't reproduce the issue...
[21:50]  * three18ti faceplam
[21:50] <holstein> yeah, it happens... no worries
[21:50] <holstein> at least you know how to troubleshoot it :)
[21:50] <three18ti> I sear I'm not crazy.
[21:50] <three18ti> *swear
[21:51] <three18ti> lol.  well thanks for the help
[21:51] <holstein> three18ti: anytime... good luck
[21:52] <three18ti> thanks.  now if only I could get this node to boot off the nfs...
[22:54] <fosburg> where do I find Type 1 fonts (helvetica) that can be installed on a linux OS?
[22:57] <holstein> fosburg: i would check out https://wiki.ubuntu.com/Fonts
[22:59] <holstein> maybe http://www.searchfreefonts.com/search/?q=helvetica for the font files?
[23:17] <asterismo> hi people
[23:17] <asterismo> simple question
[23:18] <asterismo> talking about performance and speed
[23:18] <asterismo> maverick vs natty vs oneiric??
[23:18] <asterismo> any opinions?
[23:51] <asterismo> hi people
[23:51] <asterismo>  simple question
[23:51] <asterismo>  talking about performance and speed
[23:51] <asterismo>  maverick vs natty vs oneiric??
[23:51] <asterismo> any opinions?
[23:56] <three18ti> what do you do when ubuntu docs say  /etc/inetd.conf should have a line in it, but your version of ubuntu doesn't use init scripts?  I feel like I should know the answer but I'm at a loss to explain why tftp doesn't work for PXE boot...


[06:55] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2741 Publishing packages
[07:06] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2744 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[07:22] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2741 Proposed pocket
[07:45] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2744 Diff missing
[08:08] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2744 Generating diffs
[08:09] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2744 Successfully built
[09:23] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2745 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[09:37] -queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2735 Needs rebuild due to new commits (zesty/mir). Successfully built (xenial/mir)
[09:38] -queuebot:#ubuntu-ci-eng- alan_g, https://bileto.ubuntu.com/#/ticket/2736 Needs rebuild due to new commits
[10:05] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2745 Ready to build (zesty/google-perftools). UNAPPROVED queue (xenial/google-perftools, yakkety/google-perftools)
[11:35] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/2745 Abandoning ticket
[15:47] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2746 No packages are being considered! If you are preparing sources manually, please upload them to the PPA now
[15:48] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2746 Generating diffs
[16:07] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/2746 Successfully built


[15:45] <coz_>  good day all
[23:03] <Cheesehead> Greetings
[23:04] <Cheesehead> Looking for an Artwork Team opinion on a Brainstorm Idea
[23:04] <Cheesehead> http://brainstorm.ubuntu.com/idea/28255/
[23:04] <Cheesehead> Has this ever been discussed before?
[23:09] <Cheesehead> Is there a known answer to the issue?
[23:10] <Cheesehead> Or is it worth voting on?
[23:54] <Cheesehead> anyone?


[11:44] <arash> stdin: man, that will take like 2 years :p
[11:45] <stdin> arash: like i said, that's when it will be installed by default. there will be packages before that
[11:46] <arash> stdin: heh :), seems neat.
[11:48] <tazgodx> i have a few packages with unmet dependency issues, is there an easy way to upgrade all the dependency issues?
[11:48] <stdin> tazgodx: try "sudo apt-get -f install"
[11:55] <giovani> hmm, I'm having some odd problems with gnome/gtk applications -- gtk themes don't seem to be working
[11:55] <giovani> when I change a gtk theme, all it does is change the colors, all the widgets remain completely blocky, square
[11:55] <giovani> the only theme that seems to alter the widgets is the Qt theme, which, I'm not interested in using
[11:55] <giovani> I should say, gtk2
[11:57] <tsdgeos> giovani: somewhere you have set to use gtk-qt engine, you have to remove it
[11:58] <tsdgeos> i think it is on kcontrol in the style section
[11:58] <giovani> tsdgeos: no ...
[11:58] <tsdgeos> something called "use this style for gtk" or something
[11:58] <giovani> no, that is not set
[11:58] <giovani> I don't see how that would make the widgets blocky -- turning that on actually works fine
[12:02] <prak> is cvs installed with kubuntu?
[12:03] <giovani> prak: not by default, no
[12:03] <giovani> the cvs package provides it
[12:04] <prak> http://www.pastebin.ca/698947, giovani
[12:04] <prak> i'm not sure if i installed it
[12:04] <prak> but basically i can't access any folders
[12:04] <giovani> did you read the error?
[12:05] <giovani> you most definitely have cvs installed, and it's working properly
[12:05] <prak> ok
[12:05] <giovani> the error clearly says "no route to host" -- you need to check your network settings, mainly the default route
[12:06] <prak> how would i check the default route in my network settings?
[12:06] <giovani> with the route command
[12:06] <giovani> there should be a line with "default" under the "Destination" column
[12:06] <giovani> that needs to be set to your gateway/router
[12:07] <giovani> you can change that information manually, but the proper debian/ubuntu method involves writing the /etc/network/interfaces file
[12:07] <giovani> or using one of the graphical network managers
[12:09] <prak> i opened the interfaces file using nano now, giovani
[12:15] <prak> it says "auto ath0"
[12:15] <prak> next line "iface ath0 inet dhcp"
[12:16] <navets> do you guys mind looking at my website and giving me suggestions for improvement; http://navetz.com
[12:18] <apetrescu> Hey, navetz
[12:18] <apetrescu> Are you Tom McDonald's friend? :p
[12:21] <tazgodx> is there a command line to dissable screensaver?
[12:22] <prak> giovani, are you still there?
[12:22] <giovani> prak: yes, I am
[12:23] <prak> on my wireless connection in interfaces file, it says "auto ath0"
[12:24] <prak> "iface ath0 inet dhcp"
[12:24] <giovani> that means it uses dhcp
[12:24] <prak> do i need to change that particular line for the cvs to work on gputils and sdcc servers?
[12:25] <giovani> this is a network issue -- I can't help you troubleshoot network problems
[12:27] <prak> ok


[02:38] <smoser> can we please get the comment linter back.
[02:38] <smoser> s/comment/commit message/
[11:18] <otubo> I want to set IPV6_AUTOCONF=NO on a link local ipv6 interface on a instance. Do I need to add a special support for it on the code, or just set it on the cloud-init configuration file? I'm not really sure after reading the code.
[11:20] <minimal> otubo: on a related vein I've wondered how to configure privext (IPv6 Privacy Extensions) on an interface
[11:24] <minimal> Folks, I believe there's an issue with MAC address handling for both v1 and v2 network config files - but I'm confused how then any of the testcases that specify MAC addresses then pass. Basically when I specify a MAC address if I don't quote the value it gets "mangled" (as seen in debug output) whereas when quoted it works as expected.
[11:40] <minimal> otubo: in tests/unittests/test_net.py there's a network config v1 example that specifies the following for a bridge (I assume same would work for a physical device):
[11:40] <minimal>                   ipv6_conf:
[11:40] <minimal>                       autoconf: 1
[11:40] <minimal>                       disable_ipv6: 1
[11:40] <minimal>                       use_tempaddr: 1
[11:40] <minimal>                       forwarding: 1
[11:51] <vijayendra> otubo, ping. This is vijayendra
[11:54] <otubo> vijayendra: pong
[11:55] <otubo> minimal: nice catch. Perhaps vijayendra could give this a try on his tests.
[11:56] <minimal> otubo: Looking further I don't see any sign of actual code using these settings...
[11:56] <vijayendra> otubo, minimal Probably I missed some info here. Joined late. Let me check in history
[11:57] <otubo> I have a thousand of meeting starting now, I'll probably join the office hours to ask this to maintainers
[11:58] <minimal> Odd_Bloke: any thoughts on the MAC address issue?
[13:09] <Odd_Bloke> smoser: Not particularly easily on GitHub, unfortunately, no: there's no structured place to put a commit message except at merge time.  We have talked about using https://bors.tech/ which does have support for using the first portion of the PR description as the commit message (because it handles the squashing) but I don't know if it has commit message linting support.
[13:11] <Odd_Bloke> So I think we'd need to modify the linter to be able to parse out the commit message, and then run it as a GH action?  (Or maybe a Travis job: as our project is public we can _probably_ just hit GitHub's API from over there instead.)
[13:11] <Odd_Bloke> minimal: Testing locally, it looks like MAC addresses that aren't all-digits are interpreted as strings as I would expect: https://paste.ubuntu.com/p/PKTvCJggvh/
[13:12] <Odd_Bloke> (Apologies if these aren't in YAML and I've completely missed the point; my pot of coffee is still brewing. ;)
[13:14] <Odd_Bloke> So if you're referencing unit tests, most of them will be passing around Python dicts, which don't have this issue (because they don't pass through YAML parsing to get mangled).
[13:50] <minimal> Odd_Bloke: what I'm seeing in the logs is the following:
[13:50] <minimal> networking.py[DEBUG]: net: waiting for expected net devices: {41135085296}
[13:50] <minimal> where "41135085296" is mangled from 52:54:00:12:34:56
[13:51] <minimal> I'm using NoCloud and have tested both v1 and v2 network config YAML files with the same behaviour
[13:54] <minimal> so I'd assumed that MAC addresses should always be quoted and was going to raise a PR to update docs and testcases accordingly - but some testcases fail it I quote their MAC addresses
[13:59] <Odd_Bloke> MAC addresses must always be strings; `52:54:00:12:34:56` is, I think, interpreted as a timestamp in YAML<PHONE_NUMBER>6 seconds since 1970) whereas `"52:54:00:12:34:56"` is a string.
[14:00] <minimal> due to this risk of misintepretation I'd expect the docs to mandate quotes around MAC addresses to avoid the issue completely
[14:02] <Odd_Bloke> Yeah, agreed; probably worth a `.. note::` or `.. warning::` in the network docs.
[14:03] <minimal> Odd_Bloke: the thing is I'd changed the docs in a PR as well as any YAML in testcases that specified MACs to quote then but multiple testcases then failed.
[14:03] <Odd_Bloke> Aha, right, I see the PR now, apologies.  Let me take a look.
[14:04] <minimal> ah, that PR doesn't have the MAC changes, I pulled it from that PR when I spotted the test failures
[14:04] <Odd_Bloke> Oh, or maybe you've pulled that chang... yep.
[14:04] <Odd_Bloke> If you could pastebin the diff of that commit, I can see if I can see anything. :)
[14:05] <minimal> there were a lot of failures in tests/unittests/test_net.py as the expected results (the quoted MACs) didn't match the actual results (non-quoted MACs)
[14:11] <Odd_Bloke> minimal: Ah yeah, it looks like some of the tests are expecting the input YAML to successfully roundtrip back out to YAML.
[14:11] <Odd_Bloke> But because the quotes aren't _necessary_ for most MAC addresses, they aren't included in the dumped YAML.
[14:11] <Odd_Bloke> And so our input quotes disappear and we have a mismatch.
[14:13] <minimal> exactly
[14:13] <minimal> so to use a horrible phrase, "how do we square this circle"? ;-)
[14:13] <amansi26> smoser:Hi smoser, I would to like to thanks for constantly reviewing my code and recommend changes to my PR https://github.com/canonical/cloud-init/pull/584 . I think we came a long way with it. I addressed all the comments on PR  . It will be great if you can review the changes once you get some time. So that any new changes recommended. I will go and addressed them quickly. Thanks
[14:17] <Odd_Bloke> minimal: So I'm not particularly concerned about those test failures: they aren't indicating that you've actually broken anything, they're just somewhat brittle tests.  So I would suggest that in a first pass, we could just not quote the specific MAC addresses in `test_net.py` that cause the failures.
[14:19] <Odd_Bloke> In terms of fixing those tests, the problem is that they expect the YAML input to be "normalised" as it were, and your change means that the input is no longer normalised.  We could address that by round-tripping the input through a dump/load before using it as the basis of comparison.
[14:19] <minimal> Odd_Bloke: hmm, ok I can have another go at figuring out which ones can safely be quoted. Do you agree the docs should be updated to effectively mandate quotes around MACs? That would avoid this sort of confusion. Think of people using the likes of Ansible and Terraform to create network config files where their code shouldn't have to have the smarts to know when to add or not add quotes
[14:22] <Odd_Bloke> If they're using a (spec-compliant) YAML library to dump some sort of datastructure, they should be fine: this isn't a bug in our YAML handling code, it's a weird corner of the spec.  But, yeah, there are plenty of cases where this could cause confusion/problems, so I agree the docs should be updated to help people avoid it.
[14:24] <minimal> Odd_Bloke: Ok I'll put something together in a PR for this. You mentioned you'd noticed PR 618 which I raised for the users and power_state quoting.
[14:24] <minimal> you'll be seeing more PRs from me in the near future as I've fixed "wakeonlan" to actually work for ENI and I've spotted an issue with static routes in ENI which I'm investigating as well.
[14:39] <Odd_Bloke> Great!
[14:41] <minimal> Odd_Bloke: I think as I'm using cloud-init in non-typical ways (mainly bootstrapping physical RPIs and x86_86 machines) that's why I'm spotting various little issues
[14:42] <Odd_Bloke> minimal: We certainly appreciate you feeding back what you're finding to us, both in terms of bugs filed and code. :)
[14:48] <meena> cool
[16:05] <Odd_Bloke> otubo: #586 landed. :)
[16:06] <otubo> Odd_Bloke: thanks a lot!
[16:07] <Odd_Bloke> Thanks for the PR!
[16:16]  * otubo waiting for office hours
[16:19] <otubo> Odd_Bloke: do we have office hours today?
[16:20] <otubo> blackboxsw: ^ :-)
[16:24] <Odd_Bloke> otubo: I don't think we're going to have a Discourse post up today, but you can consider office hours officially open. :)
[16:24] <otubo> Odd_Bloke: I just have two quick questions :-)
[16:25] <otubo> Odd_Bloke: I want to set IPV6_AUTOCONF=NO on a link local ipv6 interface on a instance. Do I need to add a special support for it on the code, or just set it on the cloud-init configuration
[16:25] <otubo> file? I'm not really sure after reading the code.
[16:26] <otubo> Odd_Bloke: and here I'm talking about RHEL/Fedora/CentOS family with NetworkManager :-)
[16:32] <Odd_Bloke> otubo: What does your current configuration look like?
[16:34] <otubo> Odd_Bloke: I don't have one yet. I was going to start adding support for it, but reading the code I didn't know for sure I needed.
[16:35] <otubo> Odd_Bloke: earlier today minimal pointed to tests/unittests/test_net.py which specifies tests for bridges:
[16:36] <otubo> ipv6_conf:
[16:36] <otubo>     autoconf: 1
[16:36] <otubo>     disable_ipv6: 1
[16:36] <otubo>     use_tempaddr: 1
[16:36] <otubo>     forwarding: 1
[16:36] <otubo> (ah, sorry for the paste)
[16:36] <otubo> Wanted to confirm I can use this configurtion for phyisical interfaces too.
[16:42] <Odd_Bloke> otubo: I'm looking, having to familiarise myself with a lot of this code.
[16:49] <Odd_Bloke> otubo: I can't find anything in the code that reads those `ipv[46]_conf` keys, and the tests still pass if I remove them: I infer that they aren't used, but I can't be sure.
[16:51] <otubo> Odd_Bloke: ok, looks like I'm gonna have some fun tomorrow debugging this :-)
[16:52] <otubo> So I'll probably need to add some support for it.
[16:54] <Odd_Bloke> As for setting IPV6_AUTOCONF=no, it looks to me like it's unconditionally set to True for `ipv6_dhcpv6-stateless` and `ipc6_slaac`: https://github.com/canonical/cloud-init/blob/master/cloudinit/net/sysconfig.py#L411 and https://github.com/canonical/cloud-init/blob/master/cloudinit/net/sysconfig.py#L428
[16:54] <Odd_Bloke> otubo: Yeah, it looks that way to me, at least.
[16:54] <Odd_Bloke> (If rharper is around, he may be able to help out a bit more.)
[16:56] <otubo> Odd_Bloke: would you think it's reasonable to override the default if user set "ipv6_autoconf: no" on configuration file?
[16:59] <rharper> Odd_Bloke: sorta;  otubo I think it would be good to understand  what IPV6_AUTOCONF means for sysconfig systems, and what NetworkManager does it it;  it's just not clear to me documentation wise;  I don't have a strong opinion on this.
[17:01] <rharper> otubo:  I think there is some common definition w.r.t autoconf between eni and sysconfig;  but I think we should collect what happens on distros to understand changes to the current default.
[17:01] <otubo> rharper: makes sense to me.
[17:02] <otubo> rharper: I don't have a particular vast background on this topic to argue that now. But I might have tomorrow after some research. I'll file a bug on Launchpad so we can discuss.
[17:04] <rharper> https://bugs.launchpad.net/cloud-init/+bug/1806014
[17:05] <otubo> well that was quick
[17:06] <otubo> rharper: before reading it, just wanted to exaplain a little bit on the background of my issue: When an instance is deployed under IBM PowerVS, it needs an ipv6 link local to communicate with the RMC module on the hypervisor.
[17:08] <otubo> rharper: apparently this interface fluctuates in stability, and it's tested that using IPV6_AUTOCONF=NO solves the problem
[17:09] <otubo> rharper: I'm not the real expert here, probably vijayendra can give more details on this.
[17:10] <rharper> well, ideally we'd root cause the problem w.r.t the variance;  vijayendra already talked with NM folks and they said you didn't tell us not to do AUTOCONF stuff and so nm is bringin the interface up and down; IIRC
 rharper, I did get in touch with nm developer but he doesn't seems to be in agreement with it. below is his explanation
 rharper, NetworkMAnager fails to get an IPv6 address and it fails the activation.
 Also, the logfile is filled with warnings and messages of the device repeatedly activating and deactivating.
 There is a cycle of NetworkManager trying to autoactivate the profile, and failing and retrying. Of course,
 the IP address thereby gets added and removed again. Fix either your configuration or your network (depending on your circumstances).
[17:13] <otubo> Interesting.
[17:14] <otubo> Yeah, I think we need to work through this a little better, because now I'm wondering why exactly the interface is behaving like that and why it's not acquiring ip.
[17:15] <rharper> for link local, ther'es no acquiring; you just have it ; link local on ivp6 is based on the device mac
[17:26] <otubo> rharper: for a reference, just found the BZ vijayendra mentioned https://bugzilla.redhat.com/show_bug.cgi?id=1888569
[17:39] <vijayendra> rharper, otubo My understanding on this is if there is no entry about IPV6_AUTOCONF, it defaults to yes and this looks for ipv6 router and when no router this ipv6 fluctuation behaviour is found
[17:41] <vijayendra> so here in case no router, we need to explicitly say IPV6_AUTOCONF=no which sets ipv6.method to either manual or link-local otherwise with AUTOCONF yes this seems to "auto" which looks for ipv6 router
[17:42] <vijayendra> but going through the cloudinig sysconfig.py code, there isn't way to do so for static configuration
[17:48] <otubo> vijayendra: did you check on this? https://bugs.launchpad.net/cloud-init/+bug/1806014
[17:49] <otubo> "When instructing cloud-init to use `type: dhcp6` for the subnet of a physical network interface, the end-result is that `/etc/sysconfig/network` contains `IPV6_AUTOCONF=no`."
[17:49] <otubo> vijayendra: ^^^
[17:49] <vijayendra> otubo, sorry I missed to check that, checking now
[17:58] <meena> i made new bug: https://bugs.launchpad.net/cloud-init/+bug/1900753
[18:04] <vijayendra> otubo, 1806014 is pretty fast. Thanks
[18:05] <otubo> vijayendra: does it solve your problem?
[18:06] <vijayendra> otubo, will have test with this new change. will update,
[18:06] <otubo> vijayendra: nice, thanks! Need to leave now
[18:06] <otubo> rharper: thanks for the pointer on that. Hopefully we won't have to touch cloud-init to make that work.
[18:08] <vijayendra> otubo, thanks
[18:35] <vijayendra> otubo,  here looks like we are doing static configuration, for static configuration, this still may not work right?
[19:04] <rharper> otubo: vijayendra:   yeah; I think there are two points here:  1) there currently isn't a way to disable Router Advertisements for ipv6 static only via network-config   2)  why does NM bounce interface configuration/ip if one does not disable RA?    ;  (1) is a reasonable bug for cloud-init;  the gap exists for openstack and network-config v1;  netplan allows control over RA   (2) is a separate issue with NM;  as I don't think RA
[19:04] <rharper> should be related to a changing IP; expecially if your environment does not have any ipv6 routers doing advertisements