Very true! (re @lubuntu_bot: (irc) <sqz1> yo..just some words of lubuntu appreciation: it's delightful to get a confirmation-popup before doing a multi-line paste into the terminal.)


[02:28]  * thumper is back
[06:25]  * thumper EODs
[08:32] <adeuring> good morning
[09:02] <mrevell> Good morning
[10:28] <thumper> jelmer: hey
[10:28] <jelmer_> thumper: Hi!
[10:28] <thumper> jelmer_: what's the status of bzr-git and dulwich?
[10:29] <thumper> jelmer_: I'd like to rollout updates
[10:33] <jelmer_> thumper: I've fixed the issue with http last week and we now import HEAD branches again, we should be able to rollout current dulwich and bzr-git's roundtrip branch.
[10:33] <thumper> so tips of both?
[10:33] <jelmer_> thumper: (did I mention 'bzr serve --git' works in a native bzr branch now?)
[10:33] <thumper> jelmer_: I think I saw your 'dent about it
[10:34] <thumper> jelmer_: how efficient is it?
[10:34] <jelmer_> thumper: It's very quick on small (small as in inventory) branches, very slow on large inventory branches
[10:34] <thumper> jelmer_: do you know why it is slow?
[10:35] <thumper> jelmer_: fixable?
[10:35] <jelmer_> thumper: Creating the Tree objects from inventories on the fly is very slow and O(size-of-tree)
[10:35]  * thumper nods
[10:35] <jelmer_> thumper: We need to cache those Tree objects, should be able to do so once jam's work on packs lands.
[10:36] <jelmer_> thumper: I'm merging the roundtrip branch into trunk atm with roundtripping itself disabled for the moment.
[10:37] <jelmer_> (it's got a lot of other improvements but I don't want to be tied to the current syntax for roundtripped data)
[10:37] <thumper> ok
[10:37] <thumper> jelmer_: just send me an email when it's ready with revnos for lp:dulwich and lp:bzr-git
[10:37] <thumper> jelmer_: and I'll get them updated
[10:41] <jelmer_> thumper: will do
[10:48] <thumper> jelmer_: thanks
[11:06] <deryck> Morning, all.
[11:07] <wgrant> jelmer_: bzr serve --git crashes for me :(
[11:07] <wgrant> AttributeError: 'BzrBackend' object has no attribute 'object_store'
[11:07] <wgrant> bzr-git/dulwich 0.5.0.
[11:16] <bigjools> morning deryck
[11:21] <jelmer_> wgrant: you need a newer dulwich, bzr-git from lp:~jelmer/bzr-git/roundtrip
[14:15] <kfogel> mrevell: it looks like RT 39801 has been done, meaning that our help and dev wikis are now editable only by members of ~launchpad-doc (for spam protection).  I'm planning to a) announce this in the appropriate places, b) document it likewise, and c) approve the currently pending team members at https://edge.launchpad.net/~launchpad-doc/+members#active.  Thoughts?
[14:17] <mrevell> kfogel, Thanks for handling that. Your plan looks ideal to me. I have two questions: do you think it's worthwhile contacting each existing member of the team directly to explain the new meaning of their membership? Also, do you think there's now a role for the team mailing list? I think "Yes" to the first and I'm not sure about the second.
[14:19] <kfogel> mrevell: I agree.  "Yes" to the first, but for the second, let's just direct people at #launchpad-dev and the other usual places if they have questions.
[14:20] <kfogel> mrevell: oh, looks like I'll need to be a team administrator.  Really, anyone in ~launchpad could be an admin.  Can we do that?
[14:22] <mrevell> kfogel, ~launchpad is now an admin of that team
[14:23] <kfogel> mrevell: fast action, sir.
[14:24] <mrevell> kfogel, :) As for contacting members directly, to tell them of the team's altered role, I don't think everyone in the team is a member of the ML
[14:24] <mrevell> kfogel, but the membership is fairly small so we can easily contact them directly
[14:25] <kfogel> mrevell: I was just going to mail them individually.
[14:25] <mrevell> cool
[14:42] <mars> jml or allenap, ping, would either of you be available to help debug a possible hang in some Unix IPC code using the subprocess module?  I have a few questions about a 40 LoC block I'm studying.
[14:43] <allenap> mars: I'll have a look.
[14:43] <mars> thanks allenap, I'm pasting it now
[14:44] <mars> allenap, http://pastebin.ubuntu.com/434980/
[14:46] <maxb> line 13, comment is lying
[14:47] <maxb> that's where you end up if the TIMEOUT runs out
[14:47] <mars> maxb, ok, that's why I asked other people :)
[14:48] <mars> maxb, so STDOUT could still be open, but the select() has timed out?
[14:48] <maxb> yes
[14:48] <mars> ok
[14:48] <mars> allenap, ^
[14:48]  * mars changes the comment
[14:49]  * maxb wonders why the code uses os.read(blah.fileno())
[14:49] <allenap> mars: Yes, I noticed that. What were your questions?
[14:49] <allenap> mars: Is it working?
[14:50] <mars> maxb, allenap, fwiw, I'm trying to figure out why the test suite is hanging with the ec2 testrunner.    But it might not be.
[14:50] <mars> allenap, I'm wondering if something in this timeout code is buggy in such a way that the test suite could hang, but this code doesn't catch and kill it.
[14:51] <mars> allenap, my XXX comments are where I would start.  They ask basic Unix programming questions that I have, that I can not answer.
[14:52] <mars> Without reading "Advanced Unix Programming".  I need the fix a bit faster than that.
[14:53] <mars> hmm
[14:54] <mars> maxb, if what you say is true...   During a hang, the test suite has stopped printing output.  That means the select() is timing out, right?
[14:54] <maxb> yes
[14:55] <mars> so that narrows the bug down to that branch of the conditional.
[14:56] <mars> so the hang is in this code path, or this code is running correctly, and the fault happens after this entire script has exited (test_on_merge.py exits correctly, but fails to send mail or something).
[14:57] <mars> maxb, allenap, is the XXX on line 17 a valid concern?
[14:57] <allenap> maxb: subprocess.Popen._communicate() does the fileno() thing. mars: Might be worth looking there and copy that select() loop as closely as possible.
[14:58] <mars> allenap, yeah, I was wondering why they didn't use .communicate().
[14:58] <allenap> mars: If proc.poll() is not None then the process has definitely terminated.
[14:59] <allenap> mars: .communicate() only returns the result at the end. Don't want to wait that long while running the test suite :)
[14:59] <maxb> Line 17 could be hit if the test process exited but a subprocess spawned by the test process still retained the open stdout file descriptor
[15:00] <mars> allenap, ah, "is not None" means it's absolutely dead.  Ok.
[15:00] <mars> I just re-read the docs, you are correct.
[15:00] <mars> maxb, oh, that is something
[15:00] <mars> it *does* do that
[15:01] <mars> the process tree on a hung server has a few defunct processes
[15:01] <mars> well, maybe
[15:03] <allenap> mars: Yeah, line 28 will kill the child, but if its children are still alive and holding a reference to proc.stdout then line 31 will hang.
[15:03] <mars> here, more info
[15:04] <mars> maxb, allenap, process tree from a hung server.  Everything is still alive!  http://pastebin.ubuntu.com/434986/
[15:04] <mars> the code never got to the killem() line :(
[15:05] <allenap> mars: The firefox has not been collected by the parent :-/
[15:05] <mars> kill_hung_process_with_a_series_of_brutish_instruments() was never called.  It will eventually SIGKILL the process in question.
[15:06] <mars> allenap, yes, on my local system I had a sort of the same thing.  I had to send SIGHUP to Python itself in order for it to get collected.
[15:06] <mars> kill -1 python-parent-process-id
[15:06] <sinzui> mrevell, which project did you have the milestone problem with?
[15:08] <mrevell> sinzui, launchpad, malone, rosetta, launchpad-registry and launchpad-foundations, so far
[15:08] <sinzui> always 10.10?
[15:08] <sinzui> ie 10.11 is always fine
[15:08] <mars> allenap, firefox was started by the windmill testrunner.  I don't see it in the tree.  That means that it died or was killed.
[15:09] <mrevell> sinzui, Yeah. Always 10.10. Everything else from 10.06 to 10.12 have been fine.
[15:10] <sinzui> mrevell, I see them, how did you create 10.10 milestones?
[15:10] <mars> allenap, maxb, that would leave the zombie processes.  So would the process tree I posted somehow lead the timeout code to hang?
[15:10] <mrevell> sinzui, I refreshed the page so that the error message was replaced by a link to a new 10.1 milestone (which I hadn't created but appeared instead of the 10.10 milestone), then went in and changed the name of the 10.1 milestone to 10.10
[15:11] <sinzui> okay thanks.
[15:12] <maxb> What is the process actually being Popen-ed here?
[15:13] <mars> maxb, line 1 of http://pastebin.ubuntu.com/434986/.
[15:15] <maxb> Did the [[[print ("\nA test appears to be hung. There has been no output for"]]] actually occur?
[15:15] <mars> allenap, maxb, here is the current code, uncommented http://pastebin.ubuntu.com/434992/.  This makes no sense:  line 19 and 23 must have run.  The processes are still alive!
[15:15] <maxb> And just what is kill_hung_process_with_a_series_of_brutish_instruments?
[15:16] <mars> maxb, that function is a rewrite I did of lines 19 through 23 of http://pastebin.ubuntu.com/434992/
[15:17] <mars> maxb, just for clarity.  The code I just pasted is what is actually run by the server, but it was too dense for me to understand.  So I rewrote and commented it before posting.
[15:17] <maxb> What is killem?
[15:17] <mars> hmm
[15:17] <maxb> It would be interesting to add some logging to see what PIDs it's *actually* sending signals to
[15:18] <mars> if we had console output for the log to write to :/
[15:18] <mars> or python standard logging installed and running in this script...
[15:19] <mars> maxb, I can add logging if that would help.
[15:19] <maxb> Well, I'm a bit baffled, so I'm clutching on to the fact that if the process is still running, a SIGKILL can't have really happened.
[15:20] <mars> maxb, here is the killem() function: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/annotate/head:/test_on_merge.py#L189
[15:20] <mars> maxb, allenap, killem() runs os.killpg(), not os.kill().  Does that matter?
[15:20] <mars> (I suspect it might?)
[15:22] <mars> hmmm
[15:22] <mars> column 3 of http://pastebin.ubuntu.com/434986/ is the process group ID
[15:22] <mars> oh
[15:22] <mars> line 6
[15:24] <mars> firefox <defunct> is part of a different process group.  But that doesn't make sense.  Could the windmill testrunner have been the target of the process group kill?
[15:26] <mars> maxb, I think you are right.  The best next step is probably to add some logging to the code to see what it is killing, and why.
[15:26] <maxb> Clearly we have an issue if the kill code is expecting the entire tree to be just one process group, but it isn't
[15:27] <allenap> mars: Where does the select() loop run? Is it in the test runner? If so, then it's running in pid 15177 and 20962.
[15:28] <allenap> mars: Ah, it's in test_on_merge.py
[15:28] <mars> allenap, sorry, I don't understand?  the select() loop is in test_on_merge.py, which... hey, if test_on_merge.py is still running, shouldn't it be in the process tree as well?
[15:29] <mars> allenap, the first column of http://pastebin.ubuntu.com/434986/ is the PPID.  Notice that it is '1' for a few of those?
[15:29] <maxb> hahahahahaha
[15:29] <allenap> mars: Yes, it should!
[15:29] <maxb> By killing the process group in this way, the supervisor script is killing itself :-)
[15:29] <mars> blah
[15:30] <allenap> maxb: Is it?
[15:30] <maxb> I tried typing out a few key lines in an interactive python
[15:31] <maxb> and that's what it seems to indicate
[15:31] <maxb> proc = Popen('sleep 3600', stdin=PIPE, stdout=PIPE, stderr=STDOUT, shell=True)
[15:31] <maxb> os.killpg(os.getpgid(proc.pid), 9)
[15:33] <allenap> maxb: But isn't it doing os.killpg(proc.pid)?
[15:33] <allenap> maxb: Scratch that.
[15:33] <allenap> Doh.
[15:34] <allenap> maxb: There's a comment in killem saying "Note that bin/test sets its process to a process group leader".
[15:34] <mars> allenap, os.killpg(os.getpgid(pid), signal)
[15:34] <maxb> allenap: oh, ok
[15:34] <maxb> hrm
[15:34] <allenap> maxb: The process tree bears that out I think.
[15:38] <allenap> mars, maxb: The Popen call has shell=True; killem() is killing the shell.
[15:39]  * allenap has to restart router
[15:52] <mars> allenap, back?
[15:52] <mars> nope, still away
[15:59] <allenap> mars: Hi. If you said anything between my last message and "allenap, back?" then I missed it.
[15:59] <mars> :)
[15:59] <mars> nope!
[15:59] <mars> allenap, thought of something
[15:59] <mars> possible cause then
[15:59] <mars> so normally, killing the shell would take everything with it
[16:00] <mars> but I have observed that Python can get deadlocked(?) on the windmill process.  Python won't respond to a SIGTERM even.    But Python ignores the shell's SIGTERM, and keeps running, along witheverything in the tree under it.
[16:02] <mars> allenap, maxb ^ does that make sense?
[16:03] <allenap> mars: That makes a lot of sense. So, perhaps send HUP or QUIT before KILL.
[16:04] <allenap> mars: Alternatively, get the Popen call to work without shell=True
[16:06] <mars> allenap, should HUP walk the process tree maybe?  This code assume that killing the shell is enough.  Obvious that is not a thorough approach.
[16:06] <allenap> mars: Or make cmdline = "exec " + cmdline
[16:06] <allenap> mars: Maybe it should, but see if this works first.
[16:07] <mars> exec would terminate the test_on_merge code path, wouldn't it?
[16:09] <allenap> mars: No, it would mean that the test process replaces the shell used to invoke it, so that killpg kills the test process group.
[16:09] <mars> oh!
[16:09] <mars> yes
[16:09] <mars> allenap, awesome, thank you
[16:09] <allenap> mars: But, I'm not sure the shell=True bit is necessary anyway.
[16:10] <mars> allenap, well, you were wondering if the entire select() loop was needed instead of just using .communicate(), so I can't say if any of this code should stay.
[16:11] <mars> allenap, they may have used their own select() loop to save .communicate() from buffering too much output.
[16:11] <mars> there is a warning in the module docs about that
[16:13] <allenap> mars: No, you definitely shouldn't use communicate(); but Popen._communicate() does have an implementation of a similar select() loop that I thought was worth studying. For example, it has an exception handler around select() to catch EINTR. Actually, other than that it's very similar.
[16:13] <allenap> mars: In any case, it doesn't look like the problem lies in that direction anyway.
[16:13] <mars> right
[16:14] <mars> well, this is one huge step closer to getting things working again
[16:19] <mars> maxb, allenap, thank you for all the help!
[16:19] <allenap> mars: You're welcome. I hope it works now :)
[17:12] <kfogel> mrevell: I think I'd like to actually deactivate the launchpad-doc@ mailing list entirely.  Its original purpose is now obsolete.  Any objections?
[17:13] <mars> leonardr, something you may find interesting: http://factoryjoe.com/blog/2010/05/16/combing-openid-and-oauth-with-openid-connect/
[17:13] <mrevell> kfogel, None at all
[17:13] <kfogel> mrevell: thanks.  Also, should I update https://help.launchpad.net/DocTeam to say it's obsolete?
[17:13] <mrevell> kfogel, Please, if you don't mind.
[17:13] <kfogel> mrevell: no problem.
[18:04] <mrevell> Night all
[21:30] <sinzui> OMG. I made staging much faster that edge.
[21:38] <cody-somerville> how?
[21:50] <thumper> sinzui: how??
[21:57] <sinzui> thumper, I used memcached tales directives on milestone and portlets. I may have fixed another issue doing this, https://staging.launchpad.net/libpng/main/+index loads faster on staging then edge for me
[21:58] <thumper> sinzui: please write it up for the list - I'm not sure how to use the memcached tales directives
[21:59] <thumper> sinzui: oh you did already
[21:59] <sinzui> thumper, I will if my branch lands. I am sure engineers will love all the broken browser tests that caching created
[21:59] <sinzui> for me
[21:59] <mars> gary_poster, ^
[22:00] <gary_poster> sinzui, yay! :-)
[22:00] <gary_poster> sinzui, that was for memcached
[22:00] <sinzui> thumper, I have not. written up what I did, yet, I just submitted the review. I want to cache some of our tales formatters if it proves to be faster than db lookups
[22:00] <sinzui> gary_poster :)
[22:02] <mars> sinzui, I wonder how many of those requests are for breadcrumbs...
[22:02] <mars> sinzui, probably not as big a payoff.  What you found is huge.
[22:02] <sinzui> mars, indeed that too crossed my mind. the header of pages can be cached. project/person displayname changes are rare.
[23:17] <lifeless> gary_poster: leonardr: ping - mod_compress
[23:17] <gary_poster> lifeless: pong, hi
[23:17] <lifeless> I'm a little surprised that you didn't just fix apacge
[23:17] <lifeless> blah, apache
[23:17] <lifeless> I wanted to check my facts at the source :)
[23:19] <leonardr> lifeless: nothing we would consider to be 'fixing apache' is acceptable to apache upstream
[23:19] <gary_poster> lifeless: :-) I'd be +1 on fixing it in apache, but from what I understood of Roy Fielding's response to the bug, the proper fix is a new filter.
[23:19] <lifeless> leonardr: oh! thats surprising
[23:19] <leonardr> see https://issues.apache.org/bugzilla/show_bug.cgi?id=39727#c31 for example
[23:20] <gary_poster> leonardr: couldn't we have made a new filter?  Or did I misunderstand Roy Fielding's suggestion?
[23:20] <lifeless> roy specifically says
[23:20] <lifeless> If mod_deflate modifies
[23:20] <lifeless> ETag on the way out, then its corresponding later requests must
[23:20] <lifeless> be reverse-modified (etags and request content) on the way back.
[23:21] <lifeless> which is completely consistent with my view, and the source of the issue [that mod_compress or whatever we're using *is violating* that MUST]
[23:21] <gary_poster> Ah, I was misrembering just a bit.  This was the line I was trying to remember:
[23:21] <gary_poster> The best solution is to implement transfer-encoding as an
[23:21] <gary_poster> http protocol filter module.
[23:22] <lifeless> well, thats TE
[23:22] <leonardr> yeah
[23:22] <lifeless> which is different
[23:22] <gary_poster> yeah
[23:22] <leonardr> that's what we tried to do, but the intermediaries stripped it
[23:22] <gary_poster> that was the misremembering part
[23:22] <leonardr> roy also rejects the solution i thought would work:
[23:22] <leonardr> Preprocessing all incoming conditional headers to remove
[23:22] <leonardr> a -gzip suffix before the request is processed won't work.
[23:22] <leonardr> In a chain of Apache servers, we won't know which server
[23:22] <leonardr> set the suffix and how many caches have stored the modified
[23:22] <leonardr> ETag versus the unmodified ETag.
[23:25] <lifeless> so
[23:25] <lifeless> a latter comment addreses that, though you have to be prescient to parse it
[23:26] <lifeless> (have each server uniquely add its suffix, and have the sysadmins be responsible for ensuring a matching back-path)
[23:26] <lifeless> I think that Apache would accept a patch which strips the -gzip, when an option is set.
[23:27] <lifeless> there are lots of special-case vs general case situations in surrogates vs http as a whole
[23:27] <leonardr> there is already a patch that strips the -gzip always
[23:27] <lifeless> ok
[23:27] <lifeless> I suggest we: get that applied to our apaches
[23:27] <lifeless>  say in the review for that patch that we need it, and discuss whats required to get it in mainline
[23:28] <leonardr> ok, what's the process for patching our apache?
[23:29] <gary_poster> so, lifeless, I have to go half an hour ago, but is this the position:
[23:29] <lifeless> also, in #squiddev I'm asking hno what he thinks the situation is
[23:29] <gary_poster> - the gzip suffix could eventually be customized
[23:29] <lifeless> [henrik nordstrom from thast bug report]
[23:29] <gary_poster> (per server)
[23:30] <gary_poster> - at that point the underlying concerns could be addressed, because that specific server's suffix could be targeted
[23:31] <lifeless> leonardr: in a chroot/vm of hardy which is what we have deployed, do an apt-get source apache2, apply the patch using whatever patch system its building with, and make sure it builds, then file an RT ticket, and include the debdiff
[23:31] <gary_poster> - meanwhile we have a hard-coded suffix.  We could have a flag to remove the suffix, whatever it is; at this point it is particularly easy, because it is hardcoded
[23:31] <lifeless> gary_poster: precisely. making it customised might be a way to get apache upstream to let useful code into their code base
[23:32] <gary_poster> lifeless: ok, thank you for the clarification.  I'm happy with that if the LOSAs are happy with that (as I expect they would be).
[23:32] <gary_poster> thank you
[23:32] <gary_poster> need to run
[23:32] <lifeless> U1 has patched their apache
[23:32] <lifeless> with a different patch, but similar sort of situation [though theirs was a simple backport]
[23:33] <lifeless> gary_poster: ciao
[23:33] <leonardr> implementing this is outside my area of competence, but if you and the losas are happy with changing apache to handle this problem, that's good news for me
[23:33] <lifeless> losa: ^ cross-check please
[23:39] <lifeless> thumper: I'm curious (as a test framework writer) what prompted lp:~thumper/launchpad/fix-factory-ids-in-tests
[23:55] <mwhudson> lifeless: a test failed in launchpad because it depended on exact values returned by the factory and miscellaneous refactoring changed that
[23:55] <mwhudson> so i changed the factory to return different values and ran the entire test suite and filed a bug with the failure
[23:55] <mwhudson> s
[23:56] <lifeless> ah
[23:56] <lifeless> I guess I meant
[23:57] <lifeless> 'why change from using the unique stuff'
[23:57] <lifeless> not 'why did some tests fail'
[23:59] <lifeless> mwhudson: ^
[23:59] <mwhudson> i haven't looked at the branch itself
[23:59] <elmo> leonardr/lifeless: I really don't want to carry a patch to apache forever; I accepted the U1 patch because it's an upstream patch


[00:38] <Hobbsee> hey there, are there plans to provide the thunderbird 3 beta 1 in a ppa?  Or even the nightlies?
[00:43] <asac> Hobbsee: we have tbird 3.0 in  ~fta ppa ... not sure if beta1 is there yet. most likely it was released while we were in uds
[00:44] <Hobbsee> asac: was released on the 8th,i tseems
[00:45] <asac> Hobbsee: yeah .. so on mondaay ;)
[00:45] <Hobbsee> cool :)
[00:53] <asac> ok so folks:
[00:53] <asac> Hobbsee: fta: [reed]: please test this:
[00:53] <asac> about:config in firefox 3.0
[00:53] <asac> reset app.update.lastUpdateTime.blocklist-background-update-timer pref
[00:53] <asac> (should be empty)
[00:54] <asac> oh sorry before everything install http liveheaders and go to capture mode ;)
[00:54] <asac> open error console in tools and do:
[00:54] <asac> Components.classes['@mozilla.org/extensions/blocklist;1'].getService(Components.interfaces.nsITimerCallback).notify(null)
[00:54] <asac> then look at http liveheaders output as it calls the block list
[00:54] <asac> copy the url that you see there
[00:54] <asac> should start with https://addons...
[00:55] <asac> what do you get?
[00:55]  * asac gets https://addons.mozilla.org/blocklist/2/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/3.0.4/Firefox/2008111319/Linux_x86_64-gcc3/chrome://global/locale/intl.properties/default/Linux%202.6.27-7-generic%20(GTK%202.14.4)/canonical/1.0/
[00:55] <asac> Jazzva: ^^ please try too
[00:55] <asac> [reed]: can you check with your build?
[00:56] <Jazzva> asac, should I get an XML file that starts with <blocklist> tag?
[00:56] <Jazzva> ah, read the backlog. will try
[00:59] <[reed]> asac: with my Ubuntu copy or my mozilla.org build?
[00:59] <asac> [reed]: since we all test with ubuntu build i am interested in your _real_ build
[01:00] <asac> or mozilla.org
[01:00] <asac> e.g. whatever you usually run
[01:00] <[reed]> ok
[01:01] <asac> Jazzva: i am interested in the GET url that is invoked
[01:01] <asac> not the result you get
[01:01] <asac> (the result should be more or less fine)
[01:03] <Jazzva> asac: https://addons.mozilla.org/blocklist/2/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/3.0.4/Firefox/2008101315/Linux_x86-gcc3/chrome://global/locale/intl.properties/default/Linux%202.6.27-9-generic%20(GTK%202.14.4)/default/default/
[01:04] <asac> yay !!!!
[01:04] <asac> [reed]: http://paste.ubuntu.com/85876/
[01:04] <asac> thats the patch
[01:04] <[reed]> asac: please file a bu
[01:04] <[reed]> bug
[01:04] <[reed]> we'll get that fixed in all branches
[01:04] <[reed]> super-quickly
[01:04] <[reed]> wow
[01:05] <[reed]> that's so bad
[01:06] <[reed]> asac: can you make sure AUS isn't doing that same dumb thing?
[01:06] <[reed]> in the update service code?
[01:06] <[reed]> if you wouldn't mind
[01:07] <asac> [reed]: i am opening bug for this blocklist
[01:07] <asac> then look at the other things as you want
[01:07] <[reed]> ok
[01:07] <[reed]> thanks
[01:08] <asac> Jazzva: can you try with upstream build?
[01:08] <asac> with fresh profile at best
[01:08] <asac> (upstream non-localized build most likely)
[01:09] <Jazzva> ok
[01:14] <asac> [reed]: filed against addon-manager (didnt fine a special blocklist component in toolkit)
[01:15] <asac> mozilla bug 469760
[01:15] <asac> will do a clean patch
[01:15] <asac> (have attached dirty one i did to verify that it works with complex pref)
[01:15] <asac> [reed]: ^^
[01:17] <asac> tried to improve summary ... guess its not much better though ;)
[01:21] <asac> [reed]: read what i posted to bug
[01:23] <asac> [reed]: i assume it means that its definitly not needed on stable branches
[01:24] <Jazzva> asac: https://addons.mozilla.org/blocklist/2/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/3.0.4/Firefox/2008102920/Linux_x86-gcc3/en-US/release-cck-mozilla04/Linux%202.6.27-9-generic%20(GTK%202.14.4)/mozilla04/1.0/
[01:24] <Jazzva> with upstream non-localized build
[01:24] <asac> yeah expected
[01:24] <asac> thanks
[01:24] <Jazzva> np :)
[01:25] <asac> [reed]: i will remove the blocking flags for the stable branches for now
[01:26] <[reed]> ok
[01:26] <asac> [reed]: but good to know ... so your current stats means most likely "all distros, but ubuntu" ;)
[01:27] <asac> [reed]: so you can probably measure the boost once it rolls ;)
[01:27] <[reed]> lol
[01:27] <[reed]> so, you're going to fix it in ubufox?
[01:27] <asac> yes ... and in firefox for the old branches
[01:27] <[reed]> k
[01:27] <asac> but those shouldnt really matter i guess
[01:29] <[reed]> please fix it ;)
[06:30] <asac> Hobbsee: btw, b1 is in ~fta PPA since 10th ... https://edge.launchpad.net/~fta/+archive?field.name_filter=thunderbird&field.status_filter=published
[10:26] <gnomefreak> Jazzva: you around?
[10:27] <gnomefreak> asac: in bug 306229 i added the info at hand. Jazzva was supposed to package it but im confused since we didnt have iceweasel in Hardy but source log says we do
[10:31] <Jazzva> gnomefreak, iceweasel-scrapbood is a transitional package. it depends on scrapbook, which is the actual one
[10:31] <Jazzva> s/scrapbood/scrapbook/
[10:32] <gnomefreak> ah ok
[10:34] <Jazzva> gnomefreak, it's actually a merge from debian, the older way of packaging is there (without mozilla-devscripts).
[10:35] <Jazzva> though, it still links to /usr/lib/iceweasel/extensions/ too. I will correct that in one of the next uploads, it's not a major bug.
[10:35] <gnomefreak> im still kind of against keeping the iceweasel transitional pakcages since we dont have ice* in our archives. if binary name dropped iceweasel and source didnt that can get confusing for users
[10:37] <gnomefreak> are all the browsers we use on deps list? i havent grabed package to look
[10:43] <Jazzva> firefox, abrowser and firefox-2. we should drop the last on. I noticed that debian has newer version of this extension, so I'll do a merge later...
[10:44] <gnomefreak> we also should have seamonkey and any other im forgetting
[10:49]  * gnomefreak has a bad feeling we are going to need a man page for vimperator
[10:49] <gnomefreak> ill be back need smoke
[11:13] <gnomefreak> why does wiki hate me so damn much
[11:15] <gnomefreak> who can tell me why when i move a package out of needs info to the ready to work on rgoup
[11:15] <gnomefreak> it doesnt stay inline with the others it doesnt conform to table surrectly
[11:43] <gnomefreak> can someone ploease let me know what is wrong with foxmarks (not fitting in tablet) on https://wiki.ubuntu.com/MozillaTeam/Extensions/List in the not sutable for Ubuntu section? i have been working on it ~30 mins cant get it aligned
[11:48] <gnomefreak> ok imm done fucking with it
[11:57] <asac> gnomefreak: probably you got the colum count wrong or something
[11:57] <asac> or maybe you lack a whitespace in front ... or miss a double ||
[12:00] <gnomefreak> ill type it over again since by looking at it its correct AFAICT but it will wait until i get coffee in me
[12:00] <gnomefreak> be back after coffee is done
[12:27] <Jazzva> asac, looks like I fixed the bug 279466
[12:29] <Jazzva> it seems foxyproxy used settingsDir for something else, then just storing settings, so it failed loading foxyproxy.js from /usr/lib/firefox/extensions/<the-rest>. I'll paste my current patch, it works, but I added one function to retrieve real settings path. Dunno if I introduced another bug by using it :)
[12:36] <asac> Jazzva: heh ... paste ;)
[12:36] <Jazzva> asac: patch http://pastebin.com/fdbe6b44
[12:37] <Jazzva> asac: calls of getDefaultPath, which returned settingsDir, throughout the old code (before patch) http://pastebin.com/f390f2122
[12:37] <Jazzva> so, i added getSettingsPath, which is modified getDefaultPath to return profile dir
[12:38] <Jazzva> I'm not sure if I should change all of those getDefaultPath that I changed, but I (quickly) changed them based on the looks of the surrounding code...
[13:03] <asac> Jazzva: so getDefaultPath is always wrong?
[13:03] <asac> maybe only the first hunk is needed (not looking at full source)
[13:03] <asac> e.g. 30/31 vs. 39/40
[13:06] <gnomefreak> wiki is fixed it needed my email
[13:08] <Jazzva> asac: well... still confused why it doesn't work when I just change settingsDir. after looking up, I noticed there is other function transformer, which calls getDefaultPath, if we're not using Portable FF. so, it old settingsDir gets resurrected there.
[13:09] <Jazzva> and it seems settingsDir is only used for settings file path... not for foxyproxy.js loading :). anyway, what do you mean 30/31 vs. 39/40?
[13:10] <Jazzva> ah, patch line number :)
[13:12] <Jazzva> my bad... so, transformer function will call getDefaultPath if we're using PFF (i suppose that's what PFF var indicated), this is how it's executed "o == this.PFF && (o = this.getDefaultPath());"
[13:13] <Jazzva> seems it's ok then... we can change getDefaultPath to getSettingsPath, and leave getDefaultPath in case of PFF (which we don't need :))...
[13:13] <gnomefreak> we have all kinds of *make apps but no damn gmake :(
[13:14] <gnomefreak> gonna guess that make is replacemnt for gmake
[13:14] <Jazzva> gnomefreak, what is gmake?
[13:14] <gnomefreak> Jazzva: wish i knew im guessing gnome make or gui make
[13:15] <gnomefreak> its a build dep listed for vimperator
[13:15] <gnomefreak> Required software to build: ¶
[13:15] <gnomefreak> * git * asciidoc (Version 8.x or newer) * zip * gmake, awk, sed, sh, echo
[13:15] <gnomefreak> oh yeah and i hate git
[13:16] <gnomefreak> awi we dont have either
[13:16] <gnomefreak> although i do remember awi from somewhere
[13:16] <Jazzva> we have awk...
[13:17] <gnomefreak> oh i typoed
[13:18] <gnomefreak> lol we have 3 choices :(
[13:23] <Jazzva> gnomefreak, if it won't build from source, you can use the existing xpi...
[13:23] <Jazzva> gnomefreak, but it should build. gmake is actually make...
[13:46] <gnomefreak> Jazzva: yeah i figured that, as for building from source it seems unlikely i will since there is 2+ extensions in one source and honestly we dont need them but i will look into it sometime in next few weeks.
[13:48] <gnomefreak> if i can hire 2 people by monday i can leave for g/f's parents house for christmas and newyears should be back by the 8th or so i got one im gonna make an offer to but cant find person #2
[13:54] <asac> gmake is gnu make aka make (as we have it installed
[13:55] <sebner> asac: gtk make would have been more fun :P
[13:55] <asac> on bsd system you usually have to install gmake in order to get a decent make ;)
[13:55] <asac> BSD make is complete crap imo ;)
[13:58] <Jazzva> I'm off till ~10pm... have to do social and school stuff outside... see you later :)
[13:58] <Jazzva> asac, I'll prepare a patch... I think it should work without using getDefaultPath (except for Portable FF), so I'll retest that tonight and submit a patch :)
[14:08] <gnomefreak> anyone getting memos from memoserv in emails?
[14:13] <gnomefreak> ha i found out :)
[21:13] <fta> hi
[22:04] <Jazzva> asac, I'll send the patch tomorrow in the morning. I'm too tired to live right now, so I'm off to sleep.
[22:13] <asac> Jazzva: sure


[07:08] <mup> PR snapd#2807 opened: snap: add new `snap switch` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/2807>
[08:17] <mup> PR snapd#3607 opened: cmd: fix re-exec bug when starting from snapd 2.21 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3607>
[08:28] <mup> PR snapd#3608 opened: cmd: rework reexec detection <Created by mvo5> <https://github.com/snapcore/snapd/pull/3608>
[08:35] <Saviq> zyga-ubuntu: the crash: http://pastebin.ubuntu.com/25131529/
[08:46] <zyga-ubuntu> Saviq: thank you
[09:35] <mup> PR snapcraft#1413 closed: core: minimal windows support <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1413>
[10:21] <mup> PR snapd#3609 opened: Introduce the kvm interface <Created by Saviq> <https://github.com/snapcore/snapd/pull/3609>
[10:35] <mup> PR snapd#3610 opened: snap: do not always quote the snap info summary <Created by mvo5> <https://github.com/snapcore/snapd/pull/3610>
[11:06]  * Chipaca in a warren of undoes
[11:08] <mup> PR snapcraft#1417 opened: Move cross-compiling from kernel to kbuild plugin <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1417>
[11:36] <zyga-ubuntu> Chipaca: hey, can you have a look at a small pr for cmd.go please?
[11:36] <zyga-ubuntu> https://github.com/snapcore/snapd/pull/3608
[11:36] <mup> PR snapd#3608: cmd: rework reexec detection <Created by mvo5> <https://github.com/snapcore/snapd/pull/3608>
[11:42] <Chipaca> zyga-ubuntu: sure
[11:43] <Chipaca> zyga-ubuntu: how will this work in places where it's not /snap?
[11:49] <zyga-ubuntu> https://lwn.net/Articles/698073/
[11:49] <zyga-ubuntu> Chipaca: it's not yet, we're aware
[11:49] <zyga-ubuntu> Chipaca: but that's for future
[11:52] <mup> PR snapd#3607 closed: cmd: fix re-exec bug when starting from snapd 2.21 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3607>
[12:00] <Chipaca> pedronis: how're you feeling today, vis-a-vis being asked for reviews?
[12:04] <pedronis> Chipaca: I'm ok
[12:09] <Chipaca> pedronis: when you have a slot, I'd appreciate a look at snapd#3600
[12:09] <mup> PR snapd#3600: many: expose service status in 'snap info' <Created by chipaca> <https://github.com/snapcore/snapd/pull/3600>
[12:11] <Chipaca> meanwhile I'm fixing a bug in snapstate's copydata thing
[12:18] <zyga-ubuntu> lip 20 14:17:55 fyke kernel: audit: type=1400 audit(1500553075.963:253): apparmor="DENIED" operation="capable" profile="/snap/core/2445/usr/lib/snapd/snap-confine" pid=10030 comm="snap-confine" capability=4  capname="fsetid"
[13:12] <mup> PR snapd#3611 opened: overlord/snapstate/backend: some copydata improvements <Created by chipaca> <https://github.com/snapcore/snapd/pull/3611>
[13:22] <pedronis> Chipaca: done
[13:29] <Chipaca> pedronis: thanks!
[13:36] <Chipaca> pedronis: I'll address your comments right now (as i just finished the copydata pr)
[13:36] <Chipaca> "just" == "just now before reading your comments and making me some tea"
[13:42] <mup> Bug #1705486 opened: SPI not working on Raspberry Pi 2 with ubuntu core <Snappy:New> <https://launchpad.net/bugs/1705486>
[13:55] <niemeyer> zyga-ubuntu: github.com/rogpeppe/govers
[13:58] <zyga-ubuntu> thanks!
[13:59] <pedronis> Chipaca: to clarify, I thing you were trying to solve that  client and deamon API are the same, so why two struct, but now you are positing client == daemon == systemd, which I'm not sure about
[14:02] <Chipaca> fair 'nuf
[14:02] <Chipaca> thing is
[14:02] <Chipaca> bah, forward-thinking to the actual services work
[14:02] <Chipaca> not sure this distinction will continue to be as clear, but ok
[14:03] <pedronis> which distinction?
[14:03] <pedronis> about systemd?
[14:03] <pedronis> the package
[14:03] <Chipaca> bah
[14:03] <Chipaca> i'm probably hung up on details of the past implementation
[14:03] <mup> PR snapd#3606 closed: cmd: fix broken double re-executiong from snapd 2.21 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3606>
[14:03] <mup> PR snapd#3608 closed: cmd: rework reexec detection <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3608>
[14:04] <Chipaca> pedronis: you're right
[14:04] <Chipaca> there's no reason this needs to be like this
[14:04]  * Chipaca fixes
[14:05] <pedronis> I understand that having two structs is more annoying than 1, but reading client in the signatures of systemd is really strange, a bit unclear if the relationship will hold
[14:05] <pedronis> but I agree we don't want/need 3 structs for this
[14:05] <zyga-ubuntu> niemeyer: we don't have to switch, upstream just merged the fix :)
[14:13] <mup> PR snapd#3612 opened: vendor: update go-flags to address crash in "snap debug" <Created by zyga> <https://github.com/snapcore/snapd/pull/3612>
[14:19] <zyga-ubuntu> Chipaca: FYI https://forum.snapcraft.io/t/snap-remove-doesnt-remove-data-from-root-snap-snap-name/1387
[14:19] <zyga-ubuntu> maybe true, maybe red herring
[14:19] <zyga-ubuntu> maybe red dwarf
[14:28] <mup> PR snapd#3525 closed: interfaces: add password-manager-service implicit classic interface (LP: #1653769) <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3525>
[14:30] <Chipaca> zyga-ubuntu: Dude.
[14:30] <zyga-ubuntu>  yes?
[14:31] <cachio> zyga-ubuntu, I have updated PR 3604 to make seccomp work for opensuse as you requested
[14:31] <cachio> zyga-ubuntu, could you take a look when you have some time?
[14:31] <zyga-ubuntu> yes, looking
[14:33] <cachio> tx
[14:34] <zyga-ubuntu> cachio: commented,
[14:36] <cachio> zyga-ubuntu, i see this error
[14:36] <cachio> https://paste.ubuntu.com/25133113/
[14:37] <cachio> when LDFLAGS contain a static link to seccomp
[14:38] <cachio> zyga-ubuntu, any idea how to deal with it?
[14:42] <mup> PR snapd#3548 closed: interfaces: Add /run/uuid/request to openvswitch <Created by coreycb> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3548>
[14:51] <zyga-ubuntu> cachio: looking
[14:51] <zyga-ubuntu> cachio: are we installing a package that ships libseccomp.a?
[14:51] <Chipaca> zyga-ubuntu: wrt "dude", commented in the forum
[14:51] <zyga-ubuntu> Chipaca: aha, thank you
[14:52] <zyga-ubuntu> :D
[14:52] <zyga-ubuntu> thanks!
[14:52] <zyga-ubuntu> so pawel reported it too :D
[14:52] <zyga-ubuntu> it must have been him then
[14:52]  * zyga-ubuntu has rusty memory
[15:05] <cachio> zyga-ubuntu, not sure but in snap-seccomp/main.go we are linking to it
[15:10] <cachio> in opensuse libseccomp.a is not included in any package that we install
[15:11] <kyrofa> Hey jdstrand, you wanted to ping you about that classic snap I'm playing with
[15:11] <cachio> zyga-ubuntu, but we need to link statically to libseccomp
[15:12] <kyrofa> I'm not awake yet and thus can't type
[15:12] <cachio> zyga-ubuntu, at least there is a test for that
[15:13] <kyrofa> jdstrand, it contains libraries for building its clients, and a tool for running several clients in a specific configuration based on a text file
[15:13] <kyrofa> It looks for those clients in the PATH
[15:14] <kyrofa> And even if the PATH is accessible in confinement, snap-confine strips it off
[15:14] <kyrofa> So if the snap is strictly confined, it can't find anything to orchestrate in e.g. the home dir
[15:14] <kyrofa> Thus classic
[15:16] <cachio> zyga-ubuntu, why we need to link statically to libseccomp in ubuntu?
[15:18] <pedronis> cachio: because of reexec
[15:19] <cachio> pedronis, to make sure both are using the same one?
[15:19] <pedronis> yes (though we don't do that with libudev because there the libudev<->kernel part is the more fragile one, but is not ideal)
[15:19] <cachio> ok
[15:20] <cachio> pedronis, thanks
[15:36] <pedronis> zyga-ubuntu: not only it was reported, but we discussed not to touch it until we have snapshots, at least that was the conclusion in London
[15:45] <kyrofa> jdstrand, moos-kyrofa is now in the review queue
[16:33] <Chipaca> pedronis: fixed snapd#3600 as per your review; thanks!
[16:33] <mup> PR snapd#3600: many: expose service status in 'snap info' <Created by chipaca> <https://github.com/snapcore/snapd/pull/3600>
[16:40] <mup> PR snapd#3596 closed: tests: disable snapd-notify for the external backend <Created by fgimenez> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3596>
[16:43] <mup> PR snapd#3503 closed: tests: add browser-support interface test <Created by fgimenez> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3503>
[16:54] <pedronis> Chipaca: generally +1 with a comment about expected in the parser
[16:58] <Chipaca> pedronis: gotcha. Yeah, it's a little convoluted as is
[16:59] <Chipaca> pedronis: by having expected be an array, you mean then doing strutil.ListContains to check for unexpected stuff?
[16:59] <Chipaca> bah, no real need, the switch handles that
[17:00] <Chipaca> hmmm
[20:17] <mup> PR snapd#3600 closed: many: expose service status in 'snap info' <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3600>


[16:04] <thafreak> grrr...
[16:04] <thafreak> TRYING to give vmware a fair shake here...
[16:05] <thafreak> but I have to run a vm on my desktop, to run the management software to connect to vmware's server
[16:05] <thafreak> and now my machine is running like crap
[16:05] <thafreak> blah
[16:06] <thafreak> and just as I sit down to start trying things again...guess who calls me
[16:06] <thafreak> a vmware sales rep
[16:07] <thafreak> I almost LOL'd at her...
[16:07] <thafreak> I was like we're not planning on spending any money on vmware, if I do use it, we'll just be using what the rest of the university already has licensed


[13:59] <sgo11> hi, I haven't installed ubuntu arm yet. I would like to know what packages and which versions are supported by current ubuntu arm release. can anyone tell me where I can check? what is the repo url? thanks.
[14:04] <ogra_> the same packages that are on x86
[14:04] <ogra_> the archive is at ports.ubuntu.com
[14:10] <sgo11> ogra_, thanks. the latest arm release is 12.04. when you say the same packages to x86, do you mean the same packages(version) as 12.04 x86? or latest 13.10 x86? thanks.
[14:10] <ogra_> the latest arm release is 13.10
[14:11] <ogra_> arm is built in parallel since 9.04, since then you have the identical package versions to x86
[14:12] <sgo11> ogra_, thanks. I come from https://wiki.ubuntu.com/ARM. it shows 12.04 release. what is the official site for ubuntu arm? where to get 13.10? thanks a lot.
[14:12] <ogra_> oh, dont trust the wiki ... it is always outdated :)
[14:13] <sgo11> ogra_, thanks. but where to get the latest arm release? thanks.
[14:13] <ogra_> there is no official site specific for arm anymore ... it is just another architecture
[14:14] <sgo11> ogra_, ok. so how can I install 13.10 to my board? can you show me some guideline/tutorial? thanks.
[14:14] <ogra_> which board is that ?
[14:15] <sgo11> ogra_, cubieboard (cubieboard3 also named cubietruck)
[14:15] <ogra_> installation images are very device specific since kernels and bootloaders vary massively on arm ... there are only images for a few devices/boards
[14:15] <ogra_> ah, well, there is definitely no official cubieboard image, so google is your friend ... i'm sure there are some third party howtos to get ubuntu running on that device though
[14:16] <sgo11> ogra_, yeah. I am a newbie to arm. I am very confused on how to install them.
[14:17] <sgo11> ogra_, the official cubieboard team release ubuntu 12.04. I just want to get latest packages. maybe I should think switching to archlinux-arm even if I never use archlinux before. but archlinux-arm provides official release to cubieboard.
[14:17] <sgo11> installation to arm world becomes very different. installation in archlinux becomes much easier than ubuntu.
[14:17] <ogra_> just use theirt image then, you can always just upgrade to 13.10
[14:18] <ogra_> huh ?
[14:18] <ogra_> i highly doubt that
[14:18] <ogra_> if there is an existing ubuntu image, just install it ... most likely you just need to dump the image onto an sd card and are good to go
[14:19] <ogra_> arch means you will have to know how to build your own stuff from scratch etc ... it will definitely be a lot harder than using a binary distro like ubuntu debian or fedora
[14:19] <sgo11> ogra_, archlinux-arm provides a specific image to my cubieboard. that's why I thought that might be easier. haven't tried it yet. I can use "sudo apt-get dist-upgrade" in ubuntu arm to upgrade to 13.10? thanks.
[14:19] <ogra_> unless you are already good at linux in general and in arch specifically
[14:20] <ogra_> sgo11, http://cubieboard.org/download/
[14:20] <ogra_> just grab the lubuntu image from there and be happy
[14:21] <ogra_> (first hit on google btw)
[14:21] <sgo11> ogra_, sorry about my bad memory. that is 12.10 instead of 12.04. but the team does not provide 13.10. how to uprgrade to 13.10 once I have 12.10? thanks.
[14:22] <ogra_> sudo update-manager-core
[14:22] <ogra_> that will upgrade you to the next ubuntu version
[14:22] <sgo11> ogra_, cool. I will do that and stick with ubuntu. thanks a lot for your help.
[14:22] <ogra_> err, sorry
[14:23] <ogra_> update-manager-core is the package
[14:23] <ogra_> it is sudo do-release-upgrade
[14:23] <sgo11> ogra_, no problem. what is the command? if you can tell me, it will save my time to google. :) thanks.
[14:23] <ogra_> sudo do-release-upgrade
[14:24] <sgo11> ogra_, oh. it's always that command. never really use it in x86 world. I always did fresh install in x86. but arm is different. thanks a lot.
[14:24] <ogra_> arm is the same :)
[14:24] <ogra_> the only things that usually differ on arm are the bootloader and kernel which are board specific
[14:24] <sgo11> ogra_, that's very cool. thank you very much! ^_^
[14:27] <sgo11> ogra_, since you are here, may I ask another question related to kernel rebuilding? can I use the same new way (https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel) to compile the kernel in arm? "fakeroot debian/rules binary-headers binary-generic" thanks.
[14:28] <ogra_> only if your kernel source has a package dir (which it is unlikely to have)
[14:29] <ogra_> the guys in #ubuntu-kernel might be able to give you more hints, but generally if you have a non official board you just build the kernel without packaging and maintain it separately
[14:30] <sgo11> ogra_, i have a driver which requires rebuild the kernel to work. that's why I asked this question in advance.
[14:30] <ogra_> well, best to ask in a cubieboard forum tzhen
[14:31] <sgo11> ogra_, sure. I will do that. thank you very much. ^_^


[01:59] <rharper> blackboxsw: Sounds good, I'll +1 the branch
[02:01] <rharper> blackboxsw: it looks like there's a package build failure related to pytest not in the build-reqs ...
[02:01] <rharper> do we need to sort that out ?
[02:33] <blackboxsw> rharper: we do unfortunately
[02:33] <blackboxsw> I'm trying to work that now
[02:37] <Goneri> rharper, I just tested on the 3 BSD, if two interfaces use DHCP, the system uses the default route of the first NIC.
[02:41] <blackboxsw> rharper: yeah I think we also need to cherry-pick the tox pytest deps changes
[02:42] <blackboxsw> cherry-pick 986f37b01
[02:42] <blackboxsw> redoing that branch now to test
[02:52] <blackboxsw> rharper: finally repushed PR 303. and added new manual steps to the PR description. basically I cherry-pick the already released 6600c642, then the tox pytest  986f37b01, then the rest of the picks
[03:08] <blackboxsw> hrm I think the build fails again the issue is that sbuild "Install cloud-init build dependencies (apt-based resolver)" gets dependencies direct from test-requirements.txt before the cpick is applied to drop nose and add pytest. So, it's not present in the sbuild image.
[03:09] <blackboxsw> even though the end result has a proper test-requirements.txt file once patches are applied
[03:09] <blackboxsw> bummer, may have to fix this tomorrow.
[14:44] <rharper> blackboxsw: I think the github CI build is just a package/bddeb; so I doesn't have any patches applied, so I think it's a funny state;
[16:57] <rharper> blackboxsw:  https://github.com/canonical/cloud-init/pull/306  is up
[17:14] <blackboxsw> ahh that makes sense rharper
[17:14] <blackboxsw> maybe we can change that too in a separate pr against cloud-init
[17:14] <blackboxsw> looking over 306
[17:15] <PodioSpaz> When using cloud-init multi-part MIME with multipass, I receive "error loading cloud-init config: yaml-cpp: error at line 5, column 13: illegal map value".
[17:17] <PodioSpaz> 1 Content-Type: multipart/mixed; boundary="[17:23] <Saviq> hi PodioSpaz, we only currently support plain user data in the --cloud-init argument
[17:25] <Saviq> there's a handful of feature requests for more complex scenarios on our github
[17:25] <Saviq> https://github.com/canonical/multipass/issues/557
[17:25] <Saviq> https://github.com/canonical/multipass/issues/1295
[17:26] <Saviq> https://github.com/canonical/multipass/issues/1040
[17:26] <Saviq> https://github.com/canonical/multipass/issues?q=is%3Aissue+is%3Aopen+cloud-init
[17:26] <Saviq> please file one for multi-part if none of those fits your use case
[17:27] <PodioSpaz> Thanks
[17:30] <blackboxsw> rharper: approved 306, needs a rebase against master
[17:30] <blackboxsw> and can land
[17:30] <blackboxsw> rharper: I'll rebase and push.
[17:34] <rharper> blackboxsw: thanks!
[17:35] <blackboxsw> ci running on it. will merge it when I see that green
[17:35] <blackboxsw> almost have new manual steps for you on release (it'll take into account your PR which we will land momentarily
[17:36] <rharper> OK
[17:58] <blackboxsw> rharper: just landed https://github.com/canonical/cloud-init/pull/306
[17:58] <blackboxsw> I'll get you the steps for focal release
[18:11] <blackboxsw> okay rharper new manual steps and push for focal release to include your 306 https://github.com/canonical/cloud-init/pull/303
[19:06] <rharper> blackboxsw: ok, running them now
[19:06] <blackboxsw> rharper: might want to refresh the pull request UI I updated the description
[19:06] <rharper> yes
[19:06] <rharper> thx
[19:06] <blackboxsw> building package now to test
[19:06] <blackboxsw> I had missed a couple things in adding my additional quilt patch
[19:10] <rharper> what's the ./picks.sh ??  is that our wrapper  you're working on ?
[19:11] <blackboxsw> rharper: that is just a script to automate the first half of the manual operations to avoid having to cut and paste each step
[19:11] <blackboxsw> so you should be able to run that directly as is.... and manually continue with =     cd cloud-init and beyond
[19:11] <rharper> hrm
[19:11] <blackboxsw> cd /tmp; bash ./picks.sh
[19:11] <rharper> why do I need it?  I've created all of the cpicks;  then I push them on
[19:12] <rharper> fix up the unittest
[19:12] <rharper> etc.
[19:12] <rharper> I don't see why I need it? (or is it automating all of the cpick work I did following your steps?)
[19:12] <rharper> sorry, I see it now
[19:12] <blackboxsw> if you've already created the cpicks. then you only need additionally to:
[19:12] <blackboxsw> cherry-pick 09fea85fd1f6fd944f4cdd8b97e283090178ae88  # your PR 306
[19:13] <blackboxsw> and the quilt push -a .... .steps below
[19:13] <rharper> gotcha
[19:13] <blackboxsw> the problem you have with your branch is that you've already updated and commited for release in debian/changelog. so you might was to get reset HEAD~1 to back off of that
[19:13] <rharper> You forgot an EOF
[19:13] <rharper> that's why
[19:13] <blackboxsw> ahh bad paste.
[19:13] <rharper> I reset to upstream/ubuntu/devel first
[19:14] <rharper> so I was replaying all of the picks from the beginning but I didn't notice it was a heredoc  ...
[19:14] <rharper> no worries.  I'm on it now
[19:14] <rharper> did you delete the trailing whitespace after removing the unittest  ?
[19:14] <rharper> oh there's the EOF ... hehe
[19:14] <blackboxsw> rharper: my EOF is middle of that description as I kicked it out during the quilt header as I figured there'd be some other wrangling
[19:14] <rharper> picks calls itself =)
[19:16] <blackboxsw> rharper: picks doesn't call itself the EOF was above that just before calling bash ./picks.sh
[19:16] <blackboxsw> I'll update the description and include the entire script within the picks.sh
[19:18] <rharper> your last git commit -am pulls in local cruft, lemme try again
[19:29] <rharper> blackboxsw: I'm pretty close; the only delta I have is in the last quilt patch (how you describe editing the unittest file)
[19:30] <rharper> https://paste.ubuntu.com/p/PDmfQ2HQwv/
[19:30] <rharper> blackboxsw: ^
[19:30] <blackboxsw> rharper: I just finally pushed again
[19:30] <blackboxsw> and updated description
[19:30] <rharper> ok, let me replay pick.sh
[19:31] <rharper> it does speed things up =)
[19:31] <blackboxsw> rharper: man , lintian is still comiing up with an error on the branch :/
[19:31] <blackboxsw> E: cloud-init changes: inconsistent-maintainer Chad Smith<EMAIL_ADDRESS>(changes vs. source) Ubuntu Developers<EMAIL_ADDRESS>[19:31] <blackboxsw> E: cloud-init: mismatch-translated-choices cloud-init/datasources choices-c
[19:31] <rharper> eww
[19:31] <blackboxsw> I'll try applying that Author instead of me
[19:32] <blackboxsw> when editing the header
[19:34] <rharper> oh, I bet you missed a file
[19:34] <rharper> the datasources choices breaks when the distro values aren't matching
[19:34] <rharper> we pulled out netbsd/openbsd  from the unittst
[19:34] <rharper> but where else are they ?
[19:35] <rharper> oh, datasource isn't distro, but when we add/remove a datasource;  isn't there some manual release branch updates ?
[19:36] <rharper> blackboxsw: ok, diff looks good, once you sort out the lintian failure
[19:38] <rharper> testing out my source package build right now
[19:41] <blackboxsw> great rharper, I'm rebuilding now with Author: Ubuntu Developers<EMAIL_ADDRESS>in the dep3 header
[19:41] <blackboxsw> to check
[19:42] <rharper> that's what I've got in mine now after your update
[19:43] <blackboxsw> rharper: looks like this https://bugs.launchpad.net/ubuntu/+source/lintian/+bug/1862787
[19:44] <rharper> ah, yes
[19:45] <blackboxsw> hrm, what does this 'mean'.  does it mean our focal images in sbuild don't yet have that released version of lintian?
[19:47] <blackboxsw> I'll ask in ubuntu-devel
[19:51] <rharper> not sure
[19:51] <rharper> Lintian: fail
[19:51] <rharper> Status: successful
[19:51] <rharper> Version: 20.1-10-g71af48df-0ubuntu13
[19:51] <rharper>
[19:52] <rharper> the package builds just fine
[19:52] <rharper> lintial errors are non-fatal to package builds
[19:52] <rharper> I know I recently asked about this when I was testing out probert packaging changes
[19:52] <rharper> blackboxsw: so, I can reproduce your branch, git diff is OK, and sbuild is OK from my perspective;
[19:53] <rharper> is your build-and-push sbuild completing with Success ?
[19:53] <blackboxsw> ahh right. ok cool. I was worried this'd break things
[19:53] <rharper> me too
[19:53] <blackboxsw> rharper: ok. then I think we are good
[19:54] <blackboxsw> I will build-and-push
[19:54] <rharper> one sec
[19:54] <blackboxsw> I have commented those operations out
[19:54] <rharper> are you going to leave the author as you or ubuntu ?
[19:54] <blackboxsw> ok holding. (and reperforming changes to track Author<EMAIL_ADDRESS>[19:54] <rharper> I'd like to get a clean diff against your branch and I'll comment with that
[19:54] <rharper> ok
[19:54] <rharper> I'll replay and diff
[19:54] <blackboxsw> yeah that was unrelated change that didn't fix anything
[19:54] <blackboxsw> same
[19:55] <blackboxsw> the issue was related the the generate *dsc file I think not the dep3 header on the patch
[19:55] <blackboxsw> sooo many cherry-picks
[19:59] <blackboxsw> rharper: force pushed and updated PR description
[19:59] <blackboxsw> building  oone more time
[20:03] <blackboxsw> rharper: +1 successful build. with latest changes.
[20:03] <blackboxsw> I won't build-and-push until you compare diffs against what I've pushed
[20:04] <rharper> blackboxsw: same here, I'm approving ;  but you push from cli, not from gui.    Do we mark approved or something else in the UI ?
[20:04] <blackboxsw> rharper: yep we push releases from cli, not github
[20:04] <rharper> is marking approve OK? it won't autoland
[20:04] <blackboxsw> to perform dput, tag and push to origin/ubuntu/devel
[20:05] <blackboxsw> correct, no auto-land in github
[20:05] <blackboxsw> ... YET. muhahhaa
[20:05] <rharper> heh, also CI will fail due to the no-patch-bddeb
[20:05] <rharper> so that'll block merging via UI
[20:05] <rharper> ok, I've Approved it
[20:05] <rharper> thanks for working on this
[20:07] <blackboxsw> schweet. rharper thanks  for the counsel here. also, I'm thinking I'll put up a tiny separate PR against ubuntu/devel now to add the debian/cloud-init-cherry-picks so we can use the uss-tableflip 'cherry-pick --pop-all' to fix daily builds
[20:08] <rharper> nice
[20:16] <blackboxsw> merged thx rharper https://github.com/canonical/cloud-init/pull/303
[20:18] <blackboxsw> powersj: rharper [ubuntu/focal-proposed] cloud-init 20.1-10-g71af48df-0ubuntu3 (Waiting for approval)
[20:23] <rharper> \o/
[20:23] <powersj> sweet