[00:37] <nagromlt> ne1 on?
[00:40] <aeoril> darkxst I believe I have successfully created the merge proposal, and it is awaiting review.  Thank you.  Next bug suggestion?
[02:12] <aeoril> darkxst oh crap - I put "Mon, 24 Feb ..." in the changelog - that should be "Tue, 24 Feb ..." - how do I fix the merge proposal?  Just fix it and do another one?  Or can I back it out somehow?
[02:30] <darkxst> aeoril, just fix it and push the extra commit, btw you should use 'dch -i' normally so you don't need to worry about date etc...
[02:31] <aeoril> darkxst yes, I saw that but only after I had made the changes - will do next time (dch -i)
[02:31] <darkxst> but you completely stuffed that branch by the looks of it
[02:32] <aeoril> darkxst what do you mean by "completely stuffed"?
[02:33] <darkxst> 573 files modified
[02:33] <darkxst> I supposed you push a branch that you had run debuild from within?
[02:33] <aeoril> hmmmm .... I must have made a mistake then ... yes, i did
[02:34] <aeoril> debuild in it - when I did bzr status, it only showed my two files changed ... what happened?
[02:34] <darkxst> aeoril, start with a clean branch, apply your icon changes (no debian changelog is actually required for ubiquity, or most ubuntu upstream branches)
[02:34] <aeoril> oh, I know - debcommit added the files before the commit - I did not want to do that - how do I clean it up before recommitting?
[02:35] <aeoril> ok, what is the best way to clean the branch?  debclean?
[02:35] <aeoril> darkxst ^
[02:35] <darkxst> (and in that case, I guess debcommit won't work without a changelog, so you would just use bzr commit)
[02:35] <darkxst> aeoril, best to start with a clean branch, debclean might work, but is often unreliable
[02:36] <aeoril> darkxst bzr commit --fixed ... ???
[02:36] <darkxst> yes that would do
[02:36] <darkxst> and once it fixed, bzr push --force-overwrite
[02:38] <aeoril> ok, will do - what is the best way to clean the branch?  In the past, I have just been deleting all the files/folders except .bzr and .bzrignore then "bzr revert" - is that as good a way as any?
[02:38] <aeoril> darkxst ^
[02:39] <darkxst> aeoril, really the best way is to start with a clean branch
[02:39] <darkxst> make a debdiff of your changes from dirty branch, and apply it to the clean branch
[02:40] <aeoril> not sure how to do either of those things, but I can look on the web
[02:40] <aeoril> (new to bzr)
[02:40] <darkxst> if there is extra stuff in the debdiff just delete it from the debdiff
[02:41] <darkxst> you make it with debdiff and apply it with patch
[02:44] <aeoril> darkxst when you say "start with a clean branch" what commands are you talking about in bzr?  I am having trouble finding out how to do that on the web
[02:46] <sarnold> bzr branch lp:... new-directory-name
[02:46] <sarnold> I think :)
[02:47] <aeoril> sarnold oh, so he is talking about creating a brand new directory and pulling fresh from lp? darkxst?
[02:47] <sarnold> aeoril: that's how I'd do it. there might be something easier but unless it's gigabytes that's pretty quick..
[02:59] <aeoril> darkxst debdiff wants the .dsc from the last version - not sure how to get that
[03:04] <aeoril> oh well, I'll just do my best
[03:15] <aeoril> sarnold darkxst so, just to make sure before I push to lp, I am going to push the clean branch with my fixes applied with: "bzr push --force-overwrite lp:~aeoril/ubuntu/vivid/ubiquity/fix-for-1422113" then go to launchpad and submit for merge?
[03:16] <aeoril> I have already downloaded the clean branch from launchpad and applied my fixes ...
[03:23] <darkxst> aeoril, yes
[03:25] <aeoril> darkxst I deleted the merge proposal.  Can you look here to see if this is good enough to merge?  Unfortunately, the commit message is lame, but I could redo that before submitting it for a merge proposal.  Also, I noticed other people are tagging their branches, so do i need to do that as well?  See here: http://bazaar.launchpad.net/~aeoril/ubuntu/vivid/ubiquity/fix-for-1422113/changes
[03:26] <aeoril> darkxst once I get it good enough to merge, I will resubmit the merge proposal again
[03:31] <aeoril> darkxst fyi it was not "--force-overwrite", just "--overwrite" ...
[03:40] <aeoril> darkxst ok, I think it is fine now.  If you do not mind looking it over, I would appreciate it before I propose it for merge:  http://bazaar.launchpad.net/~aeoril/ubuntu/vivid/ubiquity/fix-for-1422113/changes
[04:16] <darkxst> aeoril, looks fine
[04:16] <darkxst> tags are normally used when making releases, no point for you to do that
[04:17] <aeoril> ok, thanks - I'll submit for merge.  I really appreciate all the help! :)
[04:17] <darkxst> commit message could mention the reason for patch though ".... to fix missing icons on Ubuntu GNOME" or something
[04:31] <aeoril> darkxst I submitted for merge, but for some reason the merge proposal included all the crap previously in the branch - wat?
[04:32] <aeoril> darkxst so, I deleted it again
[04:34] <darkxst> aeoril, it may have just shown you the old diff (they are not generated instantly I think)? that branch is certainly fine
[04:35] <aeoril> darkxst hmmm ... it took a while and said "generating diff" - then it showed it after about ten minutes, but it was the old diff
[04:35] <darkxst> no idea then
[04:35] <aeoril> darkxst anyway, I'll worry about it tomorrow.  Thanks again
[05:49] <pitti> Good morning
[05:49] <pitti> smoser: I am now
[07:47] <dholbach> good morning
[08:05] <seb128> hey dho
[08:05] <seb128> l
[08:05] <seb128> grrr
[08:05] <seb128> hey dholbach :-)
[08:06] <dholbach> hey s
[08:06] <dholbach> eb
[08:06] <dholbach> 128
[08:06] <dholbach> 8
[08:06] <dholbach> 8
[08:08] <seb128> dholbach, :-)
[08:53] <pitti> Laney: can you please add a force-badtest for linux 3.16.0-23.31? that added some new tests, and one needs fixing
[08:53] <pitti> apw ^ FYI
[08:53] <pitti> Laney: if you would rather want to hold back that new kernel, I'm also happy to override it on my side, to let initramfs-tools through
[09:07] <Laney> pitti: I could, there's beta freeze on though so it won't make a difference today
[09:15] <pitti> Laney: ah, ok
[09:16] <Laney> pitti: is someone looking at the linux test, OOI?
[09:16] <pitti> Laney: still, not sure when the test will be fixed, but I doubt it's by Friday, so the override would still be appreciated
[09:16] <pitti> Laney: AFAIUI yes, the kernel team knows about this problem
[09:16] <Laney> *nod*
[09:29] <ev> xnox: ipv6? Is that still a thing?
[09:30] <flexiondotorg> Morning
[09:32] <xnox> ev: i guess you use this thing http://tnx.nl/legacy-ip-only.svg
[09:34] <ev> ha!
[09:35] <flexiondotorg> cjwatson, Can you just clrify the role of seeds and meta-packages (derived from seeds) in building the livefs and installing Ubuntu?
[09:35] <flexiondotorg> cjwatson, My understanding is that seeds are used to determine what goes into the livefs? But I am unclear what the meta packages are for.
[09:36] <ev> xnox: yeah, ubuntu and osx got full of hipsters, so I've gone back to this http://www.groupe-arcole.net/img/bagueAs400.jpg
[09:40] <mitya57> ev: that is a very cool dark Gtk+ theme, and I also like the auto-hidden desktop panels :-)
[09:40] <ev> hahaha
[09:41] <Laney> flashbacks to a job I had back in school
[10:01] <aeoril> Does anyone know why the diff for this merge proposal is so huge when I have only made minor changes to one file? https://code.launchpad.net/~aeoril/ubuntu/vivid/ubiquity/fix-for-1422113/+merge/250894
[10:03] <mlankhorst> pitti: hm I've noticed that mesa + gmsh has a pass now in update-excuses, instead of FAILED..
[10:04] <mlankhorst> though it's still failing on i386 obviously
[10:13] <pitti> mlankhorst: yes, I overrode it some 30 mins ago
[10:14] <mlankhorst> ah
[10:21] <cjwatson> flexiondotorg: it varies a bit, but normally metapackages are less important for actually building the livefs, but they're important to end up on the installed system because it gives people an indication of what they shouldn't remove because it's part of their baseline desktop environment; also it's useful for people who already have an installed system to be able to "apt-get install ubuntu-mate-core ubuntu-mate-desktop" and get ...
[10:21] <cjwatson> ... something reasonable
[10:22] <flexiondotorg> cjwatson, Thanks.
[10:22] <flexiondotorg> So, if I am purely concerned with building the livefs the seeds are king. The meta packages if slightly different from the seeds is not super critical. Does that sounds fair.
[10:23] <cjwatson> flexiondotorg: seeds aren't used as you describe *directly*, but they're used in the process of generating tasks (basically corresponding to dependency-expanded seed output) which are used directly
[10:23] <flexiondotorg> cjwatson, Understood.
[10:23] <flexiondotorg> Great. Thanks.
[10:23] <cjwatson> flexiondotorg: more or less, but note that the metapackages are themselves part of the task, so if you allow them to drift too much you will have problems
[10:24] <cjwatson> oh, except they're not part of the task yet.  they should be, that's a bug in your seeds
[10:24] <cjwatson> how about I fix that :)
[10:25] <cjwatson> flexiondotorg: BTW you probably shouldn't have an ubuntu-mate-live metapackage.  We don't use the metapackage there
[10:33] <aeoril> darkxst well, everything seems in place now and the merge proposal is ready for review.  I had to got to #ubuntu-motu to get help.  Also, there is a #ubuntu-installer channel.  I had to upload to lp:ubiquity, not lp:ubuntu/ubiquity.  That was the entire problem from the beginning.
[10:34] <aeoril> s/upload/do the merge proposal to/
[10:34] <darkxst> aeoril, didnt I tell you already that the branch was lp:ubiquity
[10:36] <aeoril> darkxst yes, that is where I pulled the branch from.  But the merge proposal gui automatically filled in lp:/ubuntu/ubiquity because I used the package style branch naming when I pushed to lp.  So, I just took the default, and it was wrong.  Laney on #ubuntu-motu pointed out what I did wrong immediately
[10:37] <aeoril> (used package style branch name but this is upstream)
[10:37] <darkxst> aeoril, ok, good you got it solved
[10:37] <flexiondotorg> cjwatson, I don't intend on letting them drift. Although the seeds and meta packages for Ubuntu MATE are ever so slightly different.
[10:38] <cjwatson> Why?
[10:38] <flexiondotorg> cjwatson, I'll remove the ubuntu-mate-live meta package. That is a hangover from my unofficial builds.
[10:38] <aeoril> darkxst if you are curious:  https://code.launchpad.net/~aeoril/ubuntu/vivid/ubiquity/fix-for-1422113/+merge/250896
[10:38] <MSHELL> mint is awsome
[10:38] <cjwatson> Right, thought so.
[10:38] <flexiondotorg> cjwatson, Beta 1 freeze I guess.
[10:38] <cjwatson> flexiondotorg: Oh, so just lagging a bit rather than an ongoing difference?
[10:38] <flexiondotorg> cjwatson, Indeed.
[10:38] <cjwatson> I should add MATE to tasksel.
[10:39] <flexiondotorg> cjwatson, Yes, please.
[10:39] <darkxst> aeoril, no almost bed time here
[10:40] <aeoril> darkxst well, thank you so much for helping me do my first fix!  I am very excited!  I hope it is acceptable and makes it into Ubuntu
[10:40] <aeoril> !
[10:40] <aeoril> darkxst I cannot tell you how much I appreciate all your help!
[10:51] <darkxst> aeoril, it will, night
[10:51] <aeoril> night, darkxst!
[10:53] <cjwatson> flexiondotorg: done, will filter its way in in time.  https://launchpad.net/ubuntu/+source/tasksel/2.88ubuntu17
[10:56] <flexiondotorg> cjwatson, Thanks.
[10:58] <flexiondotorg> cjwatson, What triggers germinate to regenerate this? -> http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-mate.vivid/
[11:00] <cjwatson> flexiondotorg: A cron job.  It's purely for debugging - that output isn't used by anything automatic.
[11:01] <flexiondotorg> cjwatson, Ah. OK. So it is a development aide.
[11:01] <flexiondotorg> cjwatson, Are the seeds regerminated when a build runs?
[11:01] <cjwatson> flexiondotorg: Right, it's mainly because generating the reverse-dependency analysis takes a while and it's useful to have it to hand.
[11:01] <cjwatson> flexiondotorg: Yes.
[11:02] <cjwatson> flexiondotorg: Also (more relevantly for live filesystems) at the end of every archive publisher run.
[11:02] <flexiondotorg> So, if I've pushed a seed change and rebuild. The resulting iso will incorporate those changes?
[11:02] <cjwatson> flexiondotorg: You need to wait for a couple of publisher runs, but it's usually fairly quick.
[11:02] <flexiondotorg> cjwatson, OK. What roughtly is the publisher interval?
[11:02] <cjwatson> flexiondotorg: Basically wait until the Task fields in the published Packages files have synced up.
[11:03] <cjwatson> flexiondotorg: Roughly, a few times an hour.
[11:03] <flexiondotorg> cjwatson, Thanks.
[11:03] <cjwatson> flexiondotorg: But it depends on load.
[11:04] <cjwatson> There's a slight hysteresis here: we run germinate at the end of each publisher run, and then incorporate its output into the results of the *next* run, provided that the suite in question has been marked dirty by something else - upload or override change.  But it's tricky to eliminate that without serious performance problems.
[11:04] <cjwatson> If you really need something quickly then #ubuntu-release can normally help you navigate the stormy waters. :-)
[11:07] <flexiondotorg> cjwatson, I will respin Ubuntu MATE beta 1 later today. I am happy to wait.
[11:07] <flexiondotorg> cjwatson, The no-install-recommends feature works a treat.
[11:08] <flexiondotorg> cjwatson, So I am exploiting it for the time being.
[11:08] <flexiondotorg> cjwatson, But I reviewed the packages last night.
[11:09] <flexiondotorg> cjwatson, There are half a dozen I will add MATE support to and update the Recommends in debian/control, so longer term I won't require no-install-recommends.
[11:09] <flexiondotorg> cjwatson, Thanks for explain how all this stuff is interconnected. Really appreciate it.
[11:10] <cjwatson> Sure.  Mostly this stuff just churns away in the background, but setting up a new flavour is one of the times it needs to be poked.
[11:13] <flexiondotorg> cjwatson, You enabled powerpc for Ubuntu MATE yesterday. Will this show up the in QA tracker or do I need to get a QA admin to do something?
[11:25] <cjwatson> flexiondotorg: Hm, I don't understand why the last build didn't produce a powerpc image, which is the first thing to investigate.  I'll have a look.
[11:25] <cjwatson> flexiondotorg: It may need a member of ubuntu-release to go and create an "Ubuntu Mate Desktop powerpc" entry on iso.qa.
[11:25] <cjwatson> Can't quite remember.  But that's after getting the build to happen at all.
[11:29] <cjwatson> Oh, in fact, I bet that this build was triggered from the tracker ...
[11:29] <cjwatson> Laney: ^- could you add "Ubuntu Mate Desktop powerpc" to iso.qa?
[11:29] <cjwatson> I forgot about the tracker often being the thing that drives this nowadays.
[11:31] <Laney> cjwatson: OK. You adding it to qa-products?
[11:32] <Laney> Huh. Someone else just added "Ubuntu MATE powerpc"
[11:38] <cjwatson> Laney: oh yeah, can do
[11:38] <cjwatson> Laney: rename, I guess?
[11:38] <cjwatson> flexiondotorg: ^- was that you?
[11:39] <flexiondotorg> Not me.
[11:39] <Laney> I'd already added it so I had to disable one of them
[11:39] <cjwatson> Laney: qa-products done
[11:39] <Laney> Ta
[11:40] <Laney> Think it's easiest to do the first build manually
[11:40] <cjwatson> shall I kick that off then?
[11:41] <Laney> Go for it
[11:41] <cjwatson> flexiondotorg: are you OK with me running an Ubuntu MATE build now, even if you might need another later?
[11:59] <flexiondotorg> cjwatson, Sure.
[12:00] <cjwatson> flexiondotorg: OK, that's running.  Should hopefully produce powerpc.
[12:00] <flexiondotorg> cjwatson, Thanks.
[13:26] <rbasak> Is reverse-depends looking at vivid as opposed to vivid-proposed?
[13:26] <rbasak> I was expecting the latter but am a bit confused by its results (eg. wrt. src:mysql-5.5 and src:mysql-5.6)
[13:29] <xnox> rbasak: i thought Laney made it look at both at one point.
[13:30] <xnox> rbasak: however reverse-depends uses server side cache, thus can be stale.
[13:30] <rbasak> The data I'm expecting is at least a week old.
[13:30] <rbasak> But the results would be different between vivid and vivid-proposed, so maybe it's just resolving the differences differently.
[13:30] <xnox> rbasak: you can commit a tracker to http://people.canonical.com/~ubuntu-archive/transitions/ which will be up to date.
[13:30] <xnox> runs every hour or so.
[13:31] <xnox> rbasak: i have access to the branch to commit trackers there, and I think so does Laney
[13:31] <rbasak> xnox: thanks. But I think I'm done with the MySQL work now anyway. I was just checking up on Galera.
[13:31] <rbasak> It's not really a full transition because the soname/sovers are the same.
[13:31] <rbasak> (no ABI bump)
[13:31] <xnox> rbasak: locally you can use apt-rdepends with "-r" to do reverse
[13:31] <xnox> (apt-rdepends -> is recurrsive, -r makes it reverse)
[13:33] <rbasak> Thanks - I didn't know about apt-rdepends somehow
[14:01] <smoser> pitti, i was going to ask about ubuntu-meta and systemd. i had thought that that change had landed and somehow the cloud images didn't get it, but now (i think) i realized that it just hadnt landed.
[14:02] <smoser> are you planning that change soon ?
[14:02] <smoser> and can you confirm for me that you'd expedt cloud images to get it ?
[14:02] <pitti> smoser: so far it's blocked on fixing NFS, which slangasek has meant to do for a while
[14:02] <pitti> slangasek: ^ is that still on your list?
[14:02] <smoser> oh my.
[14:03] <pitti> smoser: https://launchpad.net/~pitti/+archive/ubuntu/systemd/+packages has an ubuntu-meta with flipped init
[14:03] <pitti> smoser: that was mostly for my upgrade tests
[14:03] <smoser> right. i saw that.
[14:03] <smoser> link to "fixing nfs" bug ?
[14:04] <pitti> smoser: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1312976
[14:05] <smoser> thanks.
[14:06] <pitti> smoser: OOI, why do you ask? testing/fixing cloud-init for systemd?
[14:06] <smoser> well, cloud-init does have systemd jobs, and those run in snappy
[14:06] <smoser> so it does work to some extent. i'm guessing there are issues, but seems functional.
[14:07] <smoser> i was just kind of trackign overall "systemd by default".
[14:07] <pitti> smoser: https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration has the remaining work
[14:07] <smoser> someone told me it was turned on byd efauult
[14:07] <smoser> right.
[14:07] <smoser> thanks
[14:07] <pitti> smoser: it's basically NFS (the above) and updating juju and maas, but we could work around the latter two
[14:10] <didrocks> pitti: btw, not sure if you noticed, by I updated all flavors plymouth themes to support the fsck messages (I linked the bug to the blueprint)
[14:13] <fabbione> imcleod: tsk....
[14:13] <fabbione> pitti: hey man
[14:14] <imcleod> fabbione: :-)
[14:14] <fabbione> roaksoax: ping
[14:14] <fabbione> imcleod: busted :P
[14:14] <pitti> didrocks: yeah, I just saw, thanks!
[14:14] <imcleod> fabbione: Ecumenical dialogue....
[14:14] <didrocks> yw ;)
[14:14] <pitti> hey fabbione, long time no see! come stai?
[14:14] <fabbione> pitti: not too bad and you?
[14:15] <pitti> fabbione: quite well, thanks
[14:15] <fabbione> pitti: do you have any clue of who is in charge of the HA stack in ubuntu?
[14:15] <fabbione> pitti: i recall ante k and roaksoax at some point.. maybe it's change
[14:15] <fabbione> d
[14:17] <pitti> fabbione: I don't know for sure, I'm afraid; but server team sounds right, i. e. roaksoax should at least know who
[14:17] <fabbione> pitti: ack thanks
[14:43] <jamespage> fabbione, what do you need to know re HA stack?
[14:43] <caribou> bdmurray: just got pinged regarding an icrease in CUPS errors since my upload but there's ony one report & I'm not entitled to look at it
[14:44] <caribou> bdmurray: should I be worried about that ?
[14:44] <fabbione> jamespage: i don't really need to know.. i am curious when you guys will pull in latest versions of corosync/pacemaker. the onces you are shipping are "old"
[14:44] <lamont> should I be concerned that when I boot the livecd on my nVidia GeForce 80400 GS that the video is completely trashed?
[14:44] <lamont> or do we just hate that nvidia card?
[14:44] <fabbione> lamont: i thought you were more of a serial console guy ;)
[14:45] <lamont> fabbione: :p
[14:45] <jamespage> fabbione, well they are in released versions of Ubuntu - don't expect new versions there
[14:46] <lamont> fabbione: my real issue is trying to debug why I seem to have completely lost my window decorrations and top-bar
[14:46] <jamespage> fabbione,vivid should be relatively up-to-date - I think I pushed updates to at least one point release off the latests releases from upstream for pacemaker/corosync
[14:46] <fabbione> jamespage: what version is in vivid?
[14:47] <jamespage> corosync 2.3.4 pacemaker 1.1.11
[14:47] <fabbione> corosync is fine, pacemkaer is "old"
[14:47] <fabbione> 1.1.12 is out
[14:47] <fabbione> soon 1.1.13
[14:47] <jamespage> well I said within a point release of latest :-)
[14:48] <tinoco> jamespage: 1.1.12 would be a good goal
[14:48] <tinoco> i've been asking debian-ha to update for a long time
[14:48] <jamespage> tinoco, I don't doubt that - how active is debian-ha?
[14:48] <roaksoax> fabbione: pong
[14:48] <tinoco> jamespage: almost dead i would say
[14:49] <tinoco> jamespage: i've cherry-picked several fixes for pacemaker/corosync
[14:49] <tinoco> and asked them long time to go to 1.1.12
[14:49] <tinoco> i think we went to 1.1.11 if im not mistaken
[14:49] <tinoco> but still.. for the next LST 1.1.12 would be awesome
[14:49] <fabbione> roaksoax: all sorted.. you are too slow ;)
[14:50] <roaksoax> haha :)
[14:56] <fabbione> tinoco: 1.1.13 is going out soon'ish
[14:57] <tinoco> fabbione: yep. in between 1.1.x and 1.1.12 i've seen several fixes
[14:57] <tinoco> regarding to lrmd and stonithd segfaults and this
[14:57] <fabbione> tinoco: yes i know
[14:58] <tinoco> anyway, going up will be good and fix the "HA" stale
[14:58] <tinoco> we are having at the moment
[15:27] <slangasek> pitti: it is still on my list, but if someone were to take it off my list that might not be a horrible thing
[16:05] <pitti> slangasek: ah, last time you seemed to want to do it yourself, and also reorg it a bit in Debian; I can try and have a look at it later
[16:06] <pitti> slangasek: but aside from that, switching the default after beta might get a bit late? do you still aim for 15.04, or should we postpone to 15.10 at this point?
[16:06] <slangasek> pitti: that's true, but at this point we need to just get it done and not block on me as maintainer
[16:06] <pitti> or we switch it late, and switch back if it causes too many problems?
[16:06] <slangasek> pitti: I think it should still be switched for 15.04
[16:07] <pitti> xnox: ah, so I was chasing apport's code for a while, and then discovered another py3-lp issue :-( filed as bug 1425575
[16:07] <xnox> pitti: hm, i was testing those and i believe binary attachments should come out bit identical....
[16:07] <xnox> pitti: i'll look into it.
[16:07] <pitti> xnox: curiously, b'\x80\xFF' * 250 (or any lower value) works fine
[16:07] <pitti> xnox: but 300 or longer starts failing
[16:08] <pitti> xnox: indeed some work, but the attached reproducer has one that fails
[16:08] <xnox> pitti: HTTP ERROR 418
[16:08] <pitti> ?
[16:09] <xnox> pitti: that's my response to "values below 300 work, higher no" =) saving explicit language.
[16:09] <xnox> pitti: http://tools.ietf.org/html/rfc7168#section-2.3.3 418 -> I'm a teapot =)
[16:09] <pitti> xnox: ah, haha!
[16:18] <pitti> xnox: on the bright side, if I fake report['CoreDump'] to something simple, I get some test passes now \o/
[16:20] <pitti> and I have some failures which I need to fix on teh apport side
[16:21] <bdmurray> pitti: I've a couple of apport merge proposals for you...
[16:54] <dkessel> ChrisTownsend: you can reach me here if you need any further info for bug 1425494. i just attached the log file
[16:54] <ChrisTownsend> dkessel: Sure thing and thanks!  I'm looking at it now.
[17:12] <pitti> bdmurray: yeah, I saw one, and another one from Chad; crawling through my backlog, I'll get to it ASAP
[17:29] <pitti> xnox: bug 1425609 too, but that one is trivial at lest
[17:29] <pitti> least
[17:29] <xnox> pitti: do assign all of them to me.
[17:29] <pitti> xnox: done; many thanks for keeping up with them!
[17:30] <xnox> pitti: if we ever finish this one, making openstack ported to python3 will be my next goal. i'll leave porting lp itself to py3 to wgrant/cjwatson.
[17:30] <xnox> =)
[17:32] <pitti> xnox: down to 2 failures and 2 errors, good progress! (with the last bug fixed locally)
[17:37] <cjwatson> xnox: one of these days
[17:38] <xnox> cjwatson: probably after implementing RFC 2324 =))))
[17:47] <alexbligh1> what is the proper way to handle config.sub and config.guess within an package that uses autoconf? If I delete them, it won't build. If I leave them there, it modifies them. This is with cdbs.
[17:49] <alexbligh1> & I have include /usr/share/cdbs/1/class/autotools.mk obviously
[17:49] <infinity> alexbligh1: Assuming the package also uses automake, and assuming it autoreconfs cleanly, you just want https://wiki.debian.org/Autoreconf#CDBS-using_packages
[17:50] <alexbligh1> infinity, I have that, plus "include /usr/share/cdbs/1/rules/autoreconf.mk"
[17:50] <infinity> alexbligh1: If one or both of those isn't true, you might want to do something more like dh_autotools-dev_updateconfig/dh_autotools-dev_restoreconfig on build/clean
[17:50] <alexbligh1> infinity, the issue is 'what do I put in git'? It appears to need the file in git in order to build, but then modifies it :-/
[17:51] <alexbligh1> infinity, or do I just let it modify it, and put the modified version in git?
[17:52] <dkessel> ChrisTownsend: btw, the unity8-lxc package from the PPA is not selected by default when using the PPA in vivid, because of the versioning scheme used. It would make it easier to test changes the numbering would be changed
[17:53] <alexbligh1> infinity, this is https://github.com/abligh/ocfs2-tools/tree/ubuntu-trusty-1.8.4 if that's interesting.
[17:56] <infinity> alexbligh1: If you're using one of the autotools helpers correctly, it should be backing up the files and restoring them on clean.
[17:57] <infinity> alexbligh1: If you're not running "fakeroot debian/rules clean" before you commit to git, you'd definitely have cruft.
[17:57] <alexbligh1> infinity, ahhh, that may well be it, thanks.
[18:01] <alexbligh1> infinity, that works - thx
[18:15] <pitti> xnox: awesome, I'm down to two failures now; it seems I now filed all remaining issues as bugs
[18:38] <rbasak> alexbligh1: so I've been looking at bug 1366174 in depth today. Looks good so far - I've been trying to poke holes in your backported patch but can't find any :)
[18:38] <alexbligh1> rbasak, great :-)
[18:38] <rbasak> alexbligh1: next I'm going to compare against upstream.
[18:38] <alexbligh1> rbasak, thanks
[18:38] <rbasak> alexbligh1: for testing, it seems to me that there are three cases.
[18:39] <rbasak> Certificate with no OCSP support served OK?
[18:39] <rbasak> Certificate with OCSP support served OK in the normal case.
[18:39] <rbasak> And revoked certificate with OCSP support causing client failure.
[18:40] <rbasak> The third might not matter from the server perspective maybe.
[18:40] <alexbligh1> rbasak, and of course 'lots of SSL sites don't crash'
[18:40] <rbasak> alexbligh1: of course :)
[18:40] <rbasak> alexbligh1: do you have thoughts on the first two? Should we be verifying both of those cases from trusty-proposed?
[18:41] <alexbligh1> rbasak, I tested (1), and yes we should test that
[18:41] <alexbligh1> rbasak, one of the apache devs tested (2) as I felt I didn't know sufficient about OSCP to test it :-)
[18:41] <rbasak> alexbligh1: thanks. I just wanted to check that my thoughts were sane. You know much more about this area than I do.
[18:41] <alexbligh1> rbasak, yes I think so.
[18:42] <rbasak> alexbligh1: I'm impressed by your patch, BTW. Deep knowledge of APR and OpenSSL's interfaces is not common. OpenSSL's API in particular.
[18:43] <alexbligh1> rbasak, OpenSSL cert handling scariness learnt on the job :-) But I wrote a non-blocking SSL handler which steeled me to the weirdness of openssl.
[18:44] <rbasak> I've written code against the DTLS API before. I understand the OpenSSL pain :)
[18:57] <ChrisTownsend> dkessel: Hey, yeah, I changed the version on an upload today:)
[18:58] <ChrisTownsend> dkessel: btw, do you have some special /home setup on your machine.  The log is claiming that it doesn't exist when trying to bind mount it, which is strange.
[19:00] <dkessel> I have /home on a separate partition from /. Nothing that special I believe, ChrisTownsend
[19:01] <ChrisTownsend> dkessel: Hmm, ok.  I'll think about why a separate partition would affect this.
[19:43] <Noskcaj> stgraber, Anything i could be doing to get a +1?
[19:47] <Suudy> So, the latest Ubuntu ABI change for 14.04 moves from 3.13.0-45 to 3.13.0-46.  Unfortunately, this change breaks my MVFS driver (for Clearcase).  It looks like they have the 3.19 version of dcache.h sucked into a 3.13.0 kernel.  Is there a way to detect this sub version (e.g. -46)?
[19:49] <dobey> Suudy: is it an ABI issue and not an API issue? is the driver closed source and not rebuildable?
[19:49] <infinity> Suudy: You might want to ask that in #ubuntu-kernel
[19:49] <dobey> also that
[19:49] <Suudy> No, I have the source.
[19:51] <Suudy> Ah!  Thanks for the pointer to #ubuntu-kernel
[21:23] <bdmurray> tumbleweed: Could the ubuntu sponsorship miner be sorted by date?
[21:24] <bdmurray> tumbleweed: Ah, I see you can sort it but could the default be date?
[22:17] <flexiondotorg> I've got some merge proposal for indicator-sound and indicator-power.
[22:18] <flexiondotorg> What is the correct repo to merge with? Because if I use lp:indicator-sound and lp:indicator-power (where I branch from) the MP generate a bazzilion changes.