[00:07] <zul> can someone de binary new python3-wsme please?
[02:03] <psusi> bloody hell, cdparanoia is complicated and poorly documented
[05:14] <m4n1sh> ev: when you are free please have a look at LP # 1192777
[05:14] <m4n1sh> I have sent you a mail with more details
[05:38] <pitti_> Good morning
[05:41] <pitti> infinity: eek! added now, but I'm afraid it'll only start collecting them from now on
[05:41] <pitti> or rather, from a month ago on
[05:42] <infinity> pitti: Oh, was it actually not collecting either?  I thought I saw ports stuff in pool, but maybe I was seeing things from previous releases, I didn't look too closely at versions. :/
[05:42] <pitti> infinity: collecting yes, but they time out after 30 days
[05:42] <infinity> If not referenced.  Right.  Ugh.
[05:42] <pitti> as there hasn't been any index to refer to them
[05:43] <infinity> I wonder just how much of the archive will be rebuilt by 14.04.  Probably all of main, at least.
[05:43] <infinity> I'd really like our ports dbgsym story to be mostly fixed by then.
[05:45] <pitti> infinity: indeed; what's the current status of that, OOI?
[05:45] <infinity> pitti: Which "that"?
[05:45] <pitti> "that" == ddebs in librarian
[05:46] <infinity> Hah.
[05:46] <infinity> We're pretty much ready to roll, just need to be sure the SAN won't explode.  Which I think it might, from last I heard.
[05:47] <infinity> pitti: But from our (soyuz) side, we're ready to flip the switch as soon as we have a green light.
[05:48] <infinity> pitti: It should already be working on dogfood (and maybe staging; wgrant?), so you can prototype new and improved ddeb-retriever behaviour, perhaps.
[05:48] <wgrant> Yeah, librarian disk space is the issue now
[05:48] <wgrant> It might be a while until that's resolved
[05:48] <wgrant> We're sorta bursting at the seams atm
[05:49] <infinity> wgrant: Does dogfood actually have some ddebs published in the primary archive somewhere, so pitti can play with what that looks like?
[05:49] <didrocks> infinity: hey, is there any code to detect some potential arch publication mismatch causing FTBFS and retrying for us?
[05:49] <wgrant> It's enabled on the DF primary archive, and can be on the stagings, but staging has no Soyuz
[05:49] <didrocks> infinity: since I enabled -proposed in the daily releases, we keep getting failures due to that
[05:49] <wgrant> I think DF's primary archive should still have some ddebs
[05:49] <wgrant> Whether you can actually get them out of it without timeouts is another question entirely.
[05:49] <infinity> didrocks: As in, arch all/any skew causing build-dep failures?
[05:50] <infinity> didrocks: If there was code that detected that, it would be awfully mean of me to not let your PPA use it, right? :)
[05:50] <didrocks> infinity: exactly (libgtk3-dev this night for instance)
[05:51] <didrocks> infinity: heh, that's my guess, but it can be as well hackish code that you won't want launchpad to have :p
[05:51] <infinity> (I actually had something in the works to turn those into proper dep-waits, cause that's what they should be, but never finished it up)
[05:51] <didrocks> agreed, they should be treated as dep-waits
[05:51] <infinity> Anyhow, your best option right now is just to retry.
[05:51] <didrocks> I guess the case to reliably detect that is not that easy :)
[05:51] <infinity> didrocks: Well, the thing is you need to drill down to find out WHAT to dep-wait ON.
[05:52] <didrocks> infinity: yeah, it's failing all my stacks though, so monkey work in the morning to relaunch everything
[05:52]  * didrocks wonders if he shouldn't turn proposed off, and only turn on when we have a desired transition
[05:52] <didrocks> for the time being
[05:52] <infinity> didrocks: Which isn't too terribly hard, wouter wrote a resolver-reduction algorithm that drills down to first causes of apt failures, but I never got around to tying it into sbuild.
[05:52] <didrocks> (and have otto supporting turning otto on and off on demand)
[05:53] <infinity> didrocks: It shouldn't fail everything all that often... If skew was that huge a problem, the whole archive would be FTBFS constantly.
[05:53] <infinity> didrocks: Perhaps you just turned this on at a particularly tumultuous time.
[05:53] <didrocks> infinity: yeah, maybe we are just unlucky since we turned in -proposed… but for the past 3 days, it's not fun, I can tell you :)
[05:55] <infinity> Anyhow, your call.  The arch skew dep-wait bug has been on my TODO for something like six years, so I imagine I won't be fixing it tomorrow.
[05:55] <infinity> Maybe I'll put it on the project hacking agenda for our release engineering sprint.
[05:56] <didrocks> infinity: yeah, I'll give it a chance for still some days and see if it's better to turn on and off (but I need to ack the testing to ensure we can have it on and off conditionnally)
[05:56] <didrocks> infinity: that would be great! But I'll try to base my decision as if this doesn't exist :)
[07:08] <dholbach> good morning
[07:14] <xnox> infinity: if that's your wish i can do full-wipe-resync for lp:ubuntu/*/eglibc branches.
[07:16] <xnox> bdmurray: if gtk fails to initialise and we have a terminal, do-release-upgrade interface should be invoked instead?!
[07:17] <jibel> cjwatson, r202 fixes virtual packages and rdeps checking when a request file is specified.
[07:24] <jibel> cjwatson, I need to improve virtual package support and not expand it to the list of providing packages when a direct dependency also provides this virtual package.
[07:25] <jibel> otherwise results are sometimes odd, for example sbuild test is triggered when citadel is uploaded because it provides mail-transport-agent
[08:07] <ev> manish: yeah, that's not intended to work yet. It should be greyed out though. I'll fix that much :)
[08:15] <seb128> cjwatson, didrocks: so, jdstrand gave a security team +1 to qtwebkit-opensource-src as a temporary solution until we have our own bindings
[08:15] <seb128> (https://bugs.launchpad.net/ubuntu/+source/qtwebkit-opensource-src/+bug/1192567/comments/1)
[08:15] <didrocks> yeah, saw that, nice! ;)
[08:15] <seb128> but we probably need MIR review still before promoting
[08:16] <didrocks> I remember to have cleanswap/reviewed the package before NEWing
[08:16] <didrocks> so it's good to me, but as I participated to it, not sure of the conflict of interests I'm usually trying to avoid
[08:16] <didrocks> but not sure as well we should wait for mterry to be up
[08:16] <seb128> who else can help here? doko?
[08:16] <didrocks> yeah, I guess
[08:28] <doko> how?
[08:31] <seb128> doko, can you help reviewing bug #1192567
[08:32] <seb128> doko, that's currently blocking saucy CD builds since the qt5 version of signon-ui made it to the archive
[08:32] <seb128> doko, we don't want to revert because it would be non trivial and would break touch images (qt4 doesn't work on there)
[08:33] <doko> ok, will look at it today
[08:35] <seb128> doko, thanks
[08:36] <seb128> doko, didrocks did a first review at upload time and was ok with them, but since he's one of those who worked on the package and got it uploaded he said he would prefer having a second review (to avoid acking his own package)
[08:44] <henrix> @pilot in
[08:55] <cjwatson> didrocks: For something outside Launchpad, perhaps edos-distcheck would do the job for you
[08:57] <cjwatson> jibel: Deployed r202, thanks!  Yeah, I can see that glitch being confusing but it isn't too horrible
[09:00] <m4n1sh> ev: I have been working on https://bugs.launchpad.net/activity-log-manager/+bug/1192778 but all I am getting is segfaults, since you know your way around the code, can you have a look at it too
[09:02] <ev> sure, I'll have a look today
[09:02] <m4n1sh> thanks a lot
[09:24] <pitti> jibel: wrt. the current nova adt failure, do we actually mail these notifications to the actual uploaders?
[09:24] <pitti> jibel: (I don't think we do)
[09:25] <jibel> pitti, I made the modification but it is not deployed.
[09:26] <jibel> pitti, now it is
[09:26] <pitti> jibel: ah, thanks
[09:26]  * pitti bounces the notification to zul then
[09:26] <cjwatson> Riddell,ScottK: Is anyone working on the way that plasma-widget-networkmanagement Breaks the version of kde-workspace-data currently in saucy?  It looks like it's been making all your images unbuildable for a few days.
[09:27] <cjwatson> Urgh, gtk+3.0/3.8.2-0ubuntu5/armhf isn't happy, is it
[09:27] <cjwatson> Threading tests or something?
[09:27] <Riddell> cjwatson: no don't think I've seen that, I'll take a look in a bit
[09:28] <cjwatson> Riddell: ta
[09:28] <cjwatson> Riddell: I thought you were auto-mailed on image build failures - is that not working?
[09:28] <seb128> cjwatson, I'm doing a build on a porter box to try figuring the gtk issue out
[09:28] <cjwatson> (That isn't meant as a passive-aggressive "why aren't you reading your build failure mail" thing, btw)
[09:28] <Riddell> cjwatson: yesterday's e-mail only says  kubuntu/dvd: precise-dvd-amd64.iso oversized by<PHONE_NUMBER> bytes<PHONE_NUMBER>)
[09:29] <cjwatson> Riddell: Not the health checks
[09:29] <cjwatson> 15187   T Jun 20 CD Image               LiveFS kubuntu/saucy/amd64 failed to build on 20130620
[09:29] <xnox> cjwatson: gtk+3.0 still building only started 40 minutes ago... so another 2h to go or so.
[09:29] <cjwatson> xnox: this time round, yes; it's been tried several times
[09:29] <cjwatson> seb128: *nod*
[09:29] <xnox> ah
[09:29] <xnox> i see....
[09:29] <seb128> cjwatson, it seems to be tests failing on "Cannot animate property 'background-image'"
[09:29] <Riddell> cjwatson: I don't think I get any other e-mail about the images
[09:30] <seb128> cjwatson, xnox: well, maybe there is a real problem, but we had flacky test issues before so I retried a build while debugging, in case that make it work this time
[09:30] <cjwatson> Riddell: /msged you the relevant headers.  Mail filter problems maybe?  It should be using the same address for both health checks and image build failures
[09:31] <yofel> cjwatson: plasma-widget-networkmanagement needs kde-workspace >= 4.10.80, that will be uploaded in the next days (today or tomorrow I guess)
[09:31]  * yofel thought that britney would've held that back...
[09:32] <cjwatson> proposed-migration doesn't check arbitrary combinations of coinstallability
[09:32] <cjwatson> In this case plasma-widget-networkmanagement doesn't depend on kde-workspace-data so there's nothing to cause it to enforce them to be coinstallable
[09:32] <yofel> ah ok, I guess that makes sense then as it doesn't really need kde-workspace
[09:32] <yofel> ok, thanks
[09:32] <cjwatson> If in doubt you can feel free to ask the release team for preemptive blocks (though too late now for this one)
[09:34] <lifeless> win 67
[09:54] <seb128> hum, I can't reproduce the gtk test issue on porter-armhf :/
[12:01] <vipzrx>  http://paste.ubuntu.com/5783426/ the tftp error log
[12:05] <vipzrx>  who can help me ?
[12:55] <free> pitti: so perhaps part of the questions are not strictly SRU-related. One question is if we should keep branching lp:ubuntu/<release>/<source> when preparing a new SRU (or any upload in fact). Afair the idea was that one would then merge back into lp:ubuntu/<release>/<source>, and upload would be automatically triggered. Not sure if this is accurate, or the plan has been dropped. Thoughts?
[12:56] <free> cjwatson: ^^^ you might know too
[13:04] <pitti> free: there are no automatic uploads
[13:04] <pitti> free: if you have an existing lp:ubuntu/release-updates/pkg branch, you are welcome to use it for MPs
[13:04] <dobey> free: generally speaking, you should pull from lp:ubuntu/<release>-proposed/<source> or lp:ubuntu/<release>-updates/<source>, and lp:ubuntu/<release>/<source> as a last case, for doing an SRU.
[13:05] <pitti> free: if you are doing the first SRU for a package, then the -proposed/-updates branch doesn't exist yet, and you better don't push it to LP and leave it to the auto-importer
[13:05] <dobey> and uploads go into <release>-proposed first, and for stable releases, lp:ubuntu/<release>/<source> will basically never change again
[13:05] <Laney> @pilot in
[13:10] <free> pitti: is there any preference re LP branches vs. debdiffs? (as details in the SRU bug) to me branches are superior to debdiffs, but not sure if there's some recommendation
[13:11] <pitti> free: most sponsors get along with both these days; personally I prefer debdiffs, but you shouldn't worry too much about that
[13:12] <free> pitti: okay, I guess they have both pros and cons. Now, one last question..
[13:12] <pitti> free: also, if you run into a package which has an outdated UDD branch (in my last sponsoring shift this applied to about a third of the packages I've touched), you better use apt-get source and debediffs
[13:12] <free> pitti: oh
[13:12] <free> pitti: that's unfortunate
[13:12] <pitti> but "bzr branch ubuntu:foo" will tell you
[13:12] <pitti> CURRENT vs OBSOLETE
[13:12] <pitti> or "OUTDATED", I think
[13:14] <free> pitti: has the number of out-of-date UUD branches increased in recent time? if so, it almost feel folks do not care about this workflow/feature anymore? Asking just to understand the situation here
[13:15] <pitti> free: could be; I don't think there's anyone actively working on them
[13:15] <free> pitti: I see
[13:15] <pitti> free: but as I said, as long as the UDD branch works, feel free to use it
[13:16] <free> pitti: yeah, apparently they've been broken for landscape-client, but still looking at it
[13:17] <free> pitti: the last thing is about bugs, https://wiki.ubuntu.com/StableReleaseUpdates#Fixing_several_bugs_in_one_upload recommends to avoid "Please SRU this"-type of bugs. But in case of landscape-client (which has an SRU exception that allows to add new features) I think it actually makes sense to have a "meta" bug. We've been doing that since ever, e.g. https://bugs.launchpad.net/landscape-client/+bug/1004678. Are we good in keeping doing
[13:17] <free> that?
[13:19] <pitti> free: unless you don't want to use an actual bug report, I think it's still ok (but that's more a question for the current SRU team)
[13:19] <didrocks> cjwatson: edos-distcheck is maybe the solution, right! It's a little bit convoluted to need that to detect the FTBFS in the ppa for that component is due to archive skew and it should just relaunch later on (with a timeout), but that can work. Just not as easy to integrate when we have multiple releases and so on :)
[13:20]  * didrocks just did some trials locally
[13:21] <free> pitti: thanks
[13:23] <cjwatson> free: I rarely find it worth bothering with branches for SRUs since there are too many weirdnesses (e.g. if there's been no upload to -proposed yet)
[13:24] <free> cjwatson: I see, then we probably want to update our procedure to use debdiffs
[13:24] <cjwatson> didrocks: or you could scan the PPA build log for "The following packages have unmet dependencies:" and flag those for "somebody needs to work out what the dep-wait here is"
[13:24] <cjwatson> Debian's archive/buildd system is better at this :-/
[13:25] <free> cjwatson: any take on the "Please SRU this"-type of bug for landscape-client? (see just above)
[13:26] <didrocks> cjwatson: yeah, I think that's a viable option, knowing that the other case will be dep-wait (like no Qt5 on powerpc), so will do that scanning, and maybe can retry after an hour, after 2 retrials, will abort.
[13:27] <cjwatson> free: it's not too unreasonable if there's something complex about the SRU itself, indeed
[13:28] <free> cjwatson: typically we address many bugs in every SRU, since we're introducing new features
[13:29] <henrix> @pilot out
[13:29] <free> cjwatson: kind of unrelated, but in light of these discussion is it fair to conclude that the Ubuntu Distributed Development project is kind of paused/abandoned?
[13:31] <cjwatson> free: maintenance mode
[13:31] <free> cjwatson: I see, thanks
[13:32] <cjwatson> free: there are some people responding to issues but it's not being actively development
[13:32] <cjwatson> *developed
[13:39]  * Laney pokes bdmurray about bug #1142947 at the top of the queue ;-)
[13:51] <smoser> does anyone *not* see this bug on saucy
[13:51] <smoser> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1191951
[13:51] <smoser> to test, just hit 'alt-f2' and try to launch something by clicking
[13:52] <sil2100> Damn this heat, I need a fan!
[13:54] <pitti> didrocks: the CI test failure in https://code.launchpad.net/~pitti/autopilot-gtk/testsuite/+merge/170607 gave me an invalid rebuild link; what's the real URL?
[13:54] <pitti> didrocks: ("http://s-jenkins:8080")
[13:54] <pitti> didrocks: or will it re-try automatically after my followup commit?
[13:54] <didrocks> pitti: I think that's more a question for mmrazik, they make you configuring the "s-jenkins" host in /etc/hosts AFAIK
[13:54] <didrocks> pitti: yes
[13:55] <pitti> ah, good; so I just need to wait?
[13:55] <didrocks> if you pushed something else, it will be retriggered
[13:55] <mmrazik> pitti: yes. you just need to wait
[13:55] <mmrazik> pitti: re s-jenkins -- I checked with IS and they don't want us to unnecessarily publish our private IPs
[13:55] <mmrazik> (even though they most likely leaked here couple of times)
[13:56] <mmrazik> so yes, we modified our /etc/hosts
[13:56] <cousteau> any reason for latex2rtf to be incredibly outdated?
[13:56] <pitti> mmrazik: ah, so perhaps this shouldn't say "click here", but "tests will be retried on new commits"?
[13:56] <cousteau> (other than it being ported from Debian)
[13:56] <cousteau> (...I guess I should just ask debian)
[13:57] <mmrazik> pitti: the "click here" is mostly there is there is some jenkins/launchpad/bzr hiccup and you want to re-trigger the build without adding a new revision
[13:57] <Laney> but most people don't even have permissions to do that
[13:57] <mmrazik> pitti: but yes. Let me add a note that if you push a new revision a new build will be performed
[13:57] <cjwatson> cousteau: saucy is up to date with upstream
[13:57] <pitti> mmrazik: thanks
[13:58] <cjwatson> cousteau: it was updated in Debian (and hence in saucy) by way of non-maintainer uploads, suggesting that the maintainer isn't terribly active
[13:58] <cousteau> well, the progression I saw was   lucid: 1.9.19 precise 1.9
[13:58] <cjwatson> https://launchpad.net/ubuntu/+source/latex2rtf
[13:58] <cjwatson> http://packages.qa.debian.org/l/latex2rtf.html
[13:58] <cjwatson> I think raring was behind because nobody noticed the pending merge
[13:58] <cousteau> .1.9.19   quantal 1.9.19   raring 1.9.19   so I assumed s* wouldn't reach 2.3.3
[13:58] <cjwatson> oh, actually because 2.3.1/2.3.3 initially went to experimental due to the Debian freeze
[13:59] <cjwatson> anyway, saucy's up to date now
[13:59] <cousteau> would it be possible to request a backport?
[14:00] <cousteau> (I installed it from source, it was easy to compile; but maybe such an old software should be avoided)
[14:01] <cjwatson> cousteau: I'm not on the backports team, but I guess so ...
[14:04] <cjwatson> cousteau: https://wiki.ubuntu.com/UbuntuBackports
[14:11] <ScottK> cjwatson: I get the emails about the failed images.  I just haven't had time to look into it the last few days.
[14:17] <pitti> mmrazik, didrocks: indeed, passed now \o/
[14:17] <didrocks> pitti: sweet! Time for ice-cream then? :)
[14:18] <pitti> didrocks: my wife should get home in 30 minutes; then, for sure!
[14:19] <cjwatson> Oh, hey, it's Debian import freeze today isn't it
[14:19] <cjwatson> I'll turn off auto-sync tonight
[14:19] <Laney> huh, that crept up
[14:20] <cjwatson> Didn't it just
[14:21] <cjwatson> Unnecessarily early nowadays in my opinion, but
[14:21] <mmrazik> pitti: is this better?
[14:21] <mmrazik> https://code.launchpad.net/~mrazik/jenkins-launchpad-plugin/rebuild-note/+merge/170632
[14:24] <pitti> mmrazik: thanks!
[14:25] <pitti> hm, that's the second autopkgtest that fails to install its dependencies in -proposed in two hours
[14:26] <pitti> perhaps the pending gtk
[14:29] <seb128> pitti, I disabled tests for gtk on armhf, it just finished to build
[14:29] <seb128> does anyone know if there is a way to downgrade packages on porter's chroots?
[14:29] <pitti> that shouldn't affect i386/amd64 installability in -proposed, though
[14:29] <seb128> pitti, it does
[14:29] <seb128> oh, no
[14:29] <seb128> not those arch, only armhf
[14:29] <pitti> anyway, I'll retry them in a couple of hours
[14:30] <seb128> hate gtk
[14:30] <pitti> quotes page :)
[14:30] <seb128> I can reproduce the test issue on a porter box
[14:30] <seb128> it doesn't like the css it gets from a gresource
[14:30] <cjwatson> I think you have to ask IS for downgrades
[14:30] <seb128> but extracting that same css with the gresource shows it's not corrupted
[14:30] <pitti> seb128: try it on the n7?
[14:31] <seb128> pitti, I guess I'm good to do that, I was trying to avoid messing up my touch image
[14:31] <seb128> gtk didn't change
[14:31] <seb128> glib didn't change
[14:31] <seb128> what changed is gcc and binutils
[14:31] <seb128> so I wonder if that's a toolchain issue
[14:31] <pitti> heh, mess up even more? I got a daily build from Friday, that has a black screen
[14:32] <seb128> pitti, mine has a week old working image I use to test system settings
[14:32] <seb128> so I'm trying to keep it working until daily is back to be working
[14:32] <seb128> otherwise if I screw it I'm without a test device
[14:32] <seb128> oh well, let's see
[14:33] <ogra_> pitti, brave people use flipped :P
[14:33] <Laney> you should still be able to install sbuild
[14:33] <Laney> without risking the rest of the system
[14:33] <seb128> yeah, let me try
[14:34] <cjwatson> does it have overlayfs now?
[14:35] <Laney> nope
[14:35] <cjwatson> aufs?
[14:35] <xnox> nexus7 sure did have overlayfs for a while now.....
[14:35] <Laney> oh, maybe it was aufs it didn't have
[14:35] <Laney> whatever mk-sbuild sets it up to use by default
[14:35]  * xnox needs to reflash to check in a second.
[14:36]  * Laney is still using the trusty panda
[14:36] <seb128> I gave my panda to chrisccoulson
[14:36] <seb128> I should get him to debug gtk for me :p
[14:37] <xnox> seb128: i'm not sure how the two correlate, surely he will simply give the panda back to you :P
[14:37] <seb128> xnox, that's not worth the trip to France :p
[14:38] <ogra_> cjwatson, no, and it wont get it (per discussion)
[14:38] <xnox> chrisccoulson: FYI, i can always take a quick eurostar trip to knock on seb128 door with a pandaboard
[14:38] <bdmurray> xnox: what about do-release-upgrade?
[14:39] <xnox> bdmurray: i might be wrong, was the fails to initialise gtk bug in update or upgrade manager?
[14:39] <ogra_> xnox, nexus7 only has overlayfs on the desktop kernel, which is bitrotting in universe
[14:39] <xnox> ogra_: *sigh*
[14:40] <bdmurray> xnox: update-manager is the command I ran
[14:40] <ogra_> and there are no pans to add any union fs capabilities to the touch kernels
[14:40] <xnox> ogra_: so which kernel are we using on touch/phablet images then?
[14:40] <ogra_> *plans
[14:40] <ogra_> xnox, linux-grouper
[14:40] <ogra_> (desktop is linux-nexus7)
[14:40] <xnox> bdmurray: ah, then ignore me. executing do-release-upgrade over ssh is no replacement for update-manager.
[14:52] <slangasek> ogra_: bitrotting in universe> ah, let me see about correcting that then
[14:52] <Quintasan> Why is the systemd package kind of useless?
[14:52] <slangasek> ogra_: we're no longer building the n7 desktop images, right?
[14:52]  * Quintasan can't find /lib/systemd/systemd binary anywhere
[14:53] <slangasek> Quintasan: Ubuntu does not support systemd as init.
[14:53] <xnox> slangasek: not since 2nd of May.
[14:53] <Quintasan> slangasek: Is that a proper reason for crippling the package?
[14:53] <slangasek> xnox: righty-o
[14:53] <slangasek> Quintasan: yes
[14:53] <ogra_> slangasek, community people do though ... as long as it does no harm i thought we can just keep it around
[14:53]  * Quintasan grabs Debian package then
[14:54] <slangasek> since the alternative to "crippling the package" is "having users make their machines unbootable"
[14:54] <slangasek> ogra_: community people do what?
[14:54] <xnox> Quintasan: only certain parts of the systemd package were carefully prepared and integrated, e.g. logind. and not _all_ of it.
[14:54] <Quintasan> slangasek: That actually kind of implies that everyone will install it when it's in the repositories even if you tell them not to
[14:54] <ogra_> slangasek, roll home brewed nexus7 images
[14:55] <ogra_> using that kernel package
[14:55] <slangasek> ogra_: you specifically said "bitrot"; we have a sunsetting policy on no-longer-maintained kernels in the archive to avoid precisely this
[14:55] <slangasek> so unless someone else in the community is taking ownership of the package, it should go away
[14:55] <slangasek> Quintasan: no, not everyone, just a non-zero number of them who will then be upset with us
[14:56] <ogra_> slangasek, well, then be it  ... we'll see who screams ... i think shadeslayer was building plasma-active images with ti though
[14:56] <Quintasan> slangasek: And now you have non-zero number of people who are upset because they can't break their system if they really want to :P
[14:56] <ogra_> *it
[14:57] <shadeslayer> ogra_: the issue is not the image
[14:57] <shadeslayer> but things like X11
[14:57] <slangasek> ogra_: maybe shadeslayer would be happier with the -grouper kernel anyway?
[14:57] <shadeslayer> which I'll try and work on next week
[14:58] <ogra_> slangasek, nope, you wont like that kernel with a desktop install and without any android userspace (and all the hacked in groups and GIDs in the rootfs etc)
[14:58] <slangasek> well, ok
[14:58] <slangasek> shadeslayer: so, linux-nexus7 is not maintained by the kernel team - do you want it? :)
[14:59] <xnox> Quintasan: logind is in the default installs of most desktopy variants in saucy and is part of standard task. So at the moment, the number of people who want to continue be able to boot their machines is far larger than people who experiment with systemd.
[14:59] <xnox> Quintasan: *systemd-init that is.
[14:59] <shadeslayer> slangasek: probably
[14:59] <shadeslayer> slangasek: but I'm no kernel dev
[14:59] <Quintasan> xnox: That kind of makes me wonder why are we still using upstart
[15:01] <slangasek> Quintasan: because upstart does its job, in spite of systemd upstream's attempts to embrace and extend init
[15:02] <shadeslayer> slangasek: feel free to drop it from the archive though, but would be nice to have the git repo still up so that I have something to stand upon
[15:02] <xnox> Quintasan: i don't understand why logind was ever added to "systemd collection of daemons", since well most of them have nothing to do with "systemd init" daemon.
[15:02] <slangasek> xnox: "embrace and extend" :)
[15:03] <slangasek> ogasawara, apw: ^^ hi, do you have any opinion on the above discussion wrt keeping the linux-nexus7 git tree around for community use?
[15:03] <Quintasan> You had to carefully prepare and integrate parts of systemd into upstart booting process where apparently upstart does it's job?
[15:04]  * Quintasan kind of does not follow that
[15:04] <Quintasan> Is logind kind of mandatory with newer kernels or something?
[15:05] <apw> slangasek, desktop is not using -mako, but using -nexus7 still?  why ?
[15:05] <slangasek> apw: see ogra for $reasons :)
[15:05] <xnox> apw: desktop does not exist in saucy, though. so raring, yes still is same since release.
[15:05] <slangasek> apw: (grouper not mako, fwiw)
[15:05] <apw> slangasek, point indeed
[15:06] <ogra_> apw, there are community people that do home brewed images using this kernel ...
[15:06] <apw> ogra_, well we won't be changing it ... ever i shouldn't think
[15:06] <ogra_> but i'm not sure thats a reason to keep it .. i mean they can use the raring one
[15:06] <apw> linux-nexus7 probabally is the raring one, and has nothing for saucy in it
[15:06] <ogra_> right
[15:07] <xnox> Quintasan: gnome project decided to mandatory depend on logind instead of consolekit, among with a few other projects.
[15:07] <apw> really that should move to a nexus7 branch in the raring repo to be consistant
[15:07] <apw> though we have no intent to like update it or anything
[15:07] <xnox> Quintasan: which is unrelated to systemd-the-init.
[15:07] <ogra_> dont we have a raring branch for it already ?
[15:07] <ogra_> the one it was built from
[15:07] <ogra_> just freeze that
[15:08] <Quintasan> xnox: So what's the exact problem of shipping systemd binaries and saying "Don't install, if you do - no support" and let people toy around?
[15:09] <apw> ogra_, yeah it is already in the raring repo as 'grouper' like in saucy, so i think there is nothing in the linux-nexus7 which is worth keeping; it is duplicative
[15:09] <slangasek> Quintasan: what's the problem with people who want to shoot themselves in the foot having to do so from source? :)
[15:10] <slangasek> "carefully prepare and integrate" - you make this sound like an ordeal.  Integrating logind with upstart was not particularly difficult
[15:10] <apw> ogra_, and the same applied to linux-nexus4
[15:10] <Quintasan> slangasek: I'd rather use Ubuntu than Gentoo if you know what I mean
[15:10] <apw> slangasek, i think linnux-nexus7 and nexus4 are both redundant copies of the branchs in raring
[15:10] <slangasek> Quintasan: no, you'd rather use systemd, and Ubuntu does not support systemd
[15:11] <slangasek> apw: right, probably true
[15:11] <shadeslayer> slangasek: btw did anyone experiement with X11 + Nexus 10 like they did with the Nexus 7?
[15:11] <ogra_> apw, wait, raring grouper is not the same as nexus7
[15:11] <Quintasan> slangasek: Neither does Debian I believe and they didn't cripple the package.
[15:11] <xnox> slangasek: integrating logind across the rest of packages was more work =) but yeah, just uploading logind was not particularly difficult.
[15:11] <ogra_> apw, i think -nexus7 could evan be from quantal
[15:11] <apw> ogra_, are you sure ?
[15:12] <xnox> Quintasan: debian's systemd is not as up to date as ubuntu one though.
[15:12] <ogra_> apw, -nexus7 has definitely all android bits disabled and carries some ubuntu patches
[15:12] <ogra_> along with a config thats synced up with panda
[15:12] <apw> Ubuntu-3.1.10-10.28 and Ubuntu-3.1.10-10.28
[15:12] <mdeslaur> Quintasan: is there a specific reason you want to use systemd?
[15:12] <ogra_> they are from the same base
[15:13] <apw> ogra_, linux-nexus7/master and raring/grouper have the exact same version number
[15:13] <ogra_> but i think -nexus7 had overlayfs, it definitely has all android bits disabled
[15:13] <apw> ogra_, and the exact same sha1
[15:13] <Quintasan> mdeslaur: I have a device which boots off a kernel that has this in init and I'd rather not tamper with that. But that's not my point here
[15:13] <ogra_> apw, hmm, then we lost the original n7 tree
[15:13] <ogra_> apw, the binaries are massively different
[15:14] <mdeslaur> Quintasan: ok, sounds like a very specific use case
[15:14] <ogra_> and you wont be able to run a desktop on the grouper kernel
[15:14] <apw> which version are you comparing with
[15:14] <ogra_> the linux-nexus7 package
[15:14] <apw> ogra_, right and you are coping that forward from quantal right?  we don't build it
[15:14] <ogra_> it is a desktop kernel
[15:14] <ogra_> well, it got copied forward, i didnt do anything :)
[15:15] <apw> linux-nexus7 | 3.1.10-10.28 | raring/universe | source
[15:15] <ogra_> right
[15:15] <apw> the _only_ version of linux-nexus7 in the archive is that one, and that has the tag on that raring branch
[15:15] <apw> so that really is the one
[15:15] <ogra_> ok
[15:15] <apw> i am sure we dropped the config when we move to saucy repos
[15:15] <ogra_> i remember we had it in a PPA for a few months before ... might be that this is what i remember
[15:16] <apw> you may have been pulling those into raring images of course, but they are saucy kernels
[15:16] <ogra_> oh, if it doesnt have the desktop config it is useless
[15:16] <slangasek> shadeslayer: not that I'm aware of, the N10 hardware has been less prevalent within the team
[15:16] <shadeslayer> oh :(
[15:16] <apw> ogra_, i am saying i think this raring one is the desktop one, the one you had in raring on the touch images was the saucy source codebase built in android land
[15:17] <apw> and we have been keeping that in our saucy repo, not raring
[15:17] <ogra_> what we had in saucy images was always called -grouper
[15:17] <apw> ogra_, right but what about all those raring-* images we had until like this week
[15:18] <apw> ogra_, those were raring yes?  but using the -grouper kernel, which is saucy regardless of the prefix
[15:18] <ogra_> apw, not sure what kernel they used, it might have even come from the android tree
[15:18] <apw> so we stoped using the raring/grouper branch long before you moved to saucy- base for your system
[15:18] <apw> ogra_, then if it iwasn't in our tree we don't have it, but the raring/grouper is the linux-nexus7 source regardless of the name
[15:18] <ogra_> ok
[15:29] <jibel> several autopkgtest failed because python3-pykde4 is not installable. The version of the sip api in pykde4 must be bumped from sip-py3api-9.2 to sip-py3api-10.0 I guess.
[15:30] <xnox> jibel: known issue, rebuilds are in progress to migrate sip4.
[15:31] <xnox> jibel: transition is happening in -proposed and eventually they should all be able to run.
[15:31] <jibel> xnox, ok, thanks
[15:43] <roadmr> cjwatson: hello! I uploaded the checkbox 0.16.2 source package yesterday, it made it into the archive, we were expecting lp:ubuntu/checkbox to show some change but there's been none. Maybe we misunderstood something about the auto-importer?
[15:45] <xnox> roadmr: failed, due to tags missmatch: http://package-import.ubuntu.com/status/checkbox.html#2013-05-15 21:45:35.640192
[15:45] <roadmr> xnox: oh great, let's see
[15:45] <xnox> roadmr: would like to wipe & replace lp:ubuntu/checkbox afresh. Or keep it forever out-of-date in current state?
[15:46] <ScottK> jibel: I'll be upload a pykde4 rebuild in ~an hour to fix that.
[15:47] <roadmr> xnox: I think we'd be OK with replacing it altogether. Better than keeping the old out-of-date branch there for all eternity..
[15:48] <jibel> ScottK, np, we deployed a new interface between britney and autopkgtest this week, and wanted to make sure the problem was not on this side. Thanks!
[15:49] <doko> Daviey, jamespage: seeing "The information on this page is private." on https://launchpad.net/builders is still not nice. can you avoid that kind of copying?
[15:50] <jamespage> doko, ah - yeah - sorry
[15:50] <jamespage> I've not got to that yet
[15:52] <roadmr> xnox: is that something I can do somehow?
[15:53] <cjwatson> doko: we should really just fix that LP bug rather than regarding it as the uploader's problem
[15:54] <doko> mehh, yes ...
[15:55] <zyga> roadmr, xnox: I'm eagerly interested in how that importer works
[15:58] <xnox> zyga: an instance of lp:udd is running that tries to work out package ancestry and correct bzr import-dsc them in the right order and right history.
[15:58] <cjwatson> doko: (it's probably bug 760303, although if you know of a different condition that triggers it, do mention it ... fancy some LP hacking?)
[15:58] <xnox> zyga: if it's view of the world doesn't match the reality based on the archive and lp:ubuntu/* and lp:debian/* branches it throws an exception.
[15:59] <doko> I was trying to avoid that ...
[15:59] <xnox> roadmr: nah, needs access to that instance.
[15:59] <cjwatson> doko: Though I'm curious, you said "copying" and that doesn't seem to match the "private recipe build" condition in that bug?
[16:00] <xnox> and launchpad.net/builders is back.
[16:00] <doko> cjwatson, jamespage: I think that was another issue, but there should be an open issue for that as well
[16:02] <Daviey> doko: How long was it blocked for?
[16:02] <doko> Daviey, I'm not looking at it every hour, just need to check if buildds get stuck during the test rebuild
[16:03] <Daviey> doko: I'm thinking, that if it was only blocked for the copy action.. which is a few mins.. it doesn't seem that much of a problem?
[16:03] <doko> like that geant build on aaxte
[16:03] <cjwatson> doko: Which specific operation of jamespage/Daviey's were you referring to?
[16:03] <jamespage> cjwatson, two ops I think
[16:03] <cjwatson> It sounds like you know which one it was and I'd like to know
[16:03] <jamespage> 1) source package copy from public ppa to private ppa
[16:03] <maxiaojun> http://www.omgubuntu.co.uk/2013/06/minor-updates-arrive-in-libreoffice-4-0-4-release
[16:04] <jamespage> 2) binary copy from private -> private
[16:04] <doko> binary copy wouldn't take that long
[16:04] <cjwatson> binary copy doesn't trigger builds so I doubt that could have rendered /builders 403
[16:04] <maxiaojun> still don't understand why ubuntu cannot always have latest minor releases of libreoffice
[16:04] <jamespage> OK - so its just 1) then
[16:04] <cjwatson> /builders has no interest in the act of copying as such
[16:05] <cjwatson> jamespage: by "source package copy", do you mean with include_binaries=False?
[16:06] <cjwatson> jamespage: Actually if you could tell me the source package name I can look it up in the logs
[16:07] <jamespage> cjwatson, swift in this case
[16:07] <jamespage> cjwatson, for reference we use copy-package from archive-tools - without --include-binaries for 1)
[16:08] <Daviey> (because the private PPA must build on bare metal, but the public one doesn't need to be)
[16:10] <cjwatson> I'll see if I can write a test case that exposes it, because it annoys me that we have to spend any time thinking about this
[16:10] <cjwatson> Should finish my current copier extension first though
[16:11] <Daviey> that sounds super cjwatson
[16:11] <jamespage> cjwatson, we have a whole load more to copy over....
[16:13] <cjwatson> jamespage: I'm certainly not going to be done before you want to proceed, and I don't think you should block on this
[16:13] <cjwatson> It's hardly a new problem
[16:13] <jamespage> okay
[16:19] <ev> manish: apologies, I haven't had any time to look at those today. I got caught up in an critical operations issue. I should have more time tomorrow though.
[16:25] <infinity> xnox: Please do, that would be lovely.
[16:33] <xnox> infinity: context - blow away lp:ubuntu/eglibc and reimport?!
[16:35] <GunnarHj> Laney: Hi, I see that you are piloting. Any chance that you can merge https://code.launchpad.net/~gunnarhj/indicator-datetime/days-months/+merge/159214 before your shift ends?
[16:35] <Laney> GunnarHj: I already pinged about that one
[16:35] <slangasek> xnox: why would a full-wipe be needed?
[16:35] <Laney> I expect cyphermox will approve once all the requested reviews come in
[16:35] <GunnarHj> Laney: There are two approvals now.
[16:35] <Laney> Usually if you request multiple reviews it's because you want them all
[16:37] <Laney> GunnarHj: So if you don't care then maybe ask cyphermox to approve it now
[16:37] <Laney> I don't have such permissions ...
[16:37] <GunnarHj> Laney: Well, Charles seems not to have been around for quite a while.
[16:38] <GunnarHj> Laney: Aha, right, it's upstream ... Will ask cyphermox.
[16:39] <xnox> slangasek: ..... or sql database surgery to match up tags & revision-ids, as per all branches you've force pushed =)
[16:39] <xnox> slangasek: do you want a dump of that db of there btw?
[16:40] <slangasek> xnox: yes, half of those weren't even force-pushed, the importer has somewhere along the way started lying
[16:40] <infinity> xnox: That was the context, yes. :)
[16:40] <charles> GunnarHj: the issue is, the gmenuification of i-datetime just landed
[16:40] <slangasek> xnox: it's not "force-pushed", it's "pushed at all" from what I see lately
[16:40] <charles> GunnarHj: I'm not sure this patch is going to go in it cleanly, reading it onw
[16:40] <charles> *now
[16:40] <slangasek> xnox: anyway, yes, I would like to get this fixed on the importer side so that it respects my authoritah
[16:42] <charles> GunnarHj: hmmm
[16:43] <xnox> slangasek: i wonder if there is command to shoot udd in the head and foget about package tags, instead of shooting the branches in the head.
[16:43] <slangasek> xnox: I don't know, but I would like there to be one :)
[16:44] <slangasek> xnox: actually, I would like it to be automatic if the contents match :P
[16:44] <xnox> slangasek: given how non-matching content of your branches at times is......
[16:45] <slangasek> xnox: erm?
[16:45] <xnox> upstart upstream .orig tarball  & some .gmo files =)
[16:45] <slangasek> xnox: if you're talking about upstart, that's because I was trying to clean up after a prior mangling
[16:45] <slangasek> a unique case
[16:46] <charles> GunnarHj: so, the actual conversion of datetime fmt strings -- ie, the call to g_date_time_format()
[16:46] <charles> GunnarHj: for the header, and for the first menuitem, it's still done in the datetime service
[16:46] <charles> GunnarHj: but for locations and appointments, it's now done in IDO in its location and appointment menuitems
[16:47] <charles> and even then, ido is just for the gtk+ frontend
[16:48] <charles> since we've de-gtk+-ified indicator-datetime, we now ship out menus that have custom logic like strftime format strings
[16:48] <charles> instead of the actual date
[16:48] <charles> so that the other side can update the menuitems on their own, and we don't have to ship out new timestamps every second or every minute
[16:50] <charles> unfortunately that makes a little more work for this patch; you'll need to split it into ido and the gmenuified datetime
[16:52] <GunnarHj> charles: Hi Charles, was just getting some coffee...
[16:52] <charles> GunnarHj: that said, I'm neutral-to-positive on the feature itself and don't mind it going in. If you revise the patch and ping me on it, I'll be happy to review
[16:53] <GunnarHj> charles: Think I'd need some more guidance about how the new design affects the patch.
[16:53] <charles> GunnarHj: looks like you added me to this review some time ago and I didn't see it. I'm sorry about that; that's my bad
[16:53] <charles> GunnarHj: sure
[16:54] <charles> so, two main ideas here
[16:54] <stokachu> Laney: pingaling
[16:54] <charles> 1. we want the indicators to be able to work everywhere, not just on gtk+ environments
[16:54] <Laney> hello stokachu!
[16:55] <charles> so we're removing gtk+ from the indicators, and shopping out the rendering to other code
[16:55] <charles> which is where IDO comes in, for the gtk+ side it's got new gtkmenuitem subclasses that handle the custom menuitem logic that used to be in indicator-datetime
[16:55] <stokachu> Laney: hey there! :D ive got a bug that I believe we have in shape for sponsorship, bug 962046
[16:56] <Laney> stokachu: OK let me look
[16:56] <stokachu> Laney: thanks!
[16:56] <Laney> You just sneaked in before I was going to sign off
[16:56] <charles> GunnarHj: for example, look at http://bazaar.launchpad.net/~indicator-applet-developers/ido/trunk.13.10/revision/131
[16:56] <stokachu> Laney: lol sorry man
[16:57] <charles> and http://bazaar.launchpad.net/~charlesk/indicator-datetime/gmenuify/view/head:/README
[16:57] <Laney> stokachu: fixed in raring?
[16:57] <Laney> Or do you not want to SRU it there?
[16:57] <stokachu> Laney: its fixed in saucy.. ah yea i need to add the nomination for that series
[16:57] <charles> GunnarHj: 2. the other side to this, is trying to send out time format strings to the clients, rather than actual time strings
[16:58] <charles> that way the client can update periodically in-house without us having to keep shipping new updates over the bus
[16:58] <Laney> stokachu: Also, I'd like it if the regression potential section listed places for testers to focus on
[16:58] <GunnarHj> charles: Thanks; seems like I have some reading-up to do.
[16:58] <charles> that's why some of the g_date_time_format() calls have been moved out of indicator-datetime
[16:59] <stokachu> Laney: ok lemme get back with the openstack guys and see what I can gather
[16:59] <Laney> stokachu: See https://wiki.ubuntu.com/StableReleaseUpdates#Procedure 3.3.3
[16:59] <stokachu> Laney: thanks for looking
[16:59] <Laney> I'll build/upload in the meanwhile
[16:59] <stokachu> ok
[16:59] <charles> GunnarHj: does that make sense?
[16:59] <sil2100> Anyone from the SRU team around?
[17:00] <GunnarHj> charles: Is the code you just pointed at not in the Ubuntu archive yet?
[17:00] <charles> GunnarHj: the IDO code is already landed
[17:00] <charles> GunnarHj: indicator-datetime should be landing today / tomorrow
[17:00] <GunnarHj> charles: Ok.
[17:01] <stokachu> Laney: im speaking to the openstack people now to get that stanza updated
[17:01] <Laney> great
[17:01] <GunnarHj> charles: Guess I'll need to study the new code then, and try to figure out what needs to be modified.
[17:02] <GunnarHj> charles: Thanks for the clarifications!
[17:02] <charles> GunnarHj:  it doesn't use dates, but if you're interested in the GMenu indicators as compared to the earlier gtk+ ones, the new indicator-power's been merged
[17:03] <GunnarHj> charles: Hmm... "it doesn't use dates" - what do you mean by that?
[17:03] <charles> GunnarHj: I mean that i-power might be useful if you're wanting to read some code to get up to speed on how the new indicator code is laid out
[17:04] <charles> GunnarHj: but it's not directly relevant to your patch / your ticket wrt date formatting
[17:04] <charles> GunnarHj: i-power's already merged
[17:04] <GunnarHj> charles: Ok.
[17:04] <charles> datetime, sound, and session are in the pipeline and should happen this week
[17:04] <charles> ...should :)
[17:07] <Laney> stokachu: I'll have to fix your version numbers. You can't have the same one in both Q and R.
[17:07] <stokachu> Laney: sorry missed that in my checks, im kind of mentoring some of the openstack guys
[17:08] <stokachu> ill make a note of that
[17:08] <Laney> stokachu: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging (linked from StableReleaseUpdates) is a good document
[17:09] <stokachu> Laney: ok cool this is helpful, im writing a document for my department to hopefully get everyone on the right track
[17:11] <charles> GunnarHj: actually I think maybe there's a simpler way for your patch to get through
[17:11] <charles> GunnarHj: let me write it up in your MP
[17:12] <GunnarHj> charles: Sounds nice. ;-) Thanks in advance!
[17:14] <Laney> stokachu: all uploaded
[17:14] <Laney> thanks!
[17:33] <charles> GunnarHj: https://code.launchpad.net/~gunnarhj/indicator-datetime/days-months/+merge/159214/comments/380144
[17:39] <manish> ev: no issues. tomorrow is fine
[18:14] <psusi> so it looks like gstreamer transitioned from 0.10 to 1.0 and we currently have both source packages.  If there's a bug that was fixed in upstream 0.11, do we update 0.10, say it's fixed in 1.0, or is it a wontfix since we're in the process of dropping 0.10 anyhow?
[18:17] <slangasek> psusi: ought to be a wontfix and an added incentive to get revdeps moved off of gstreamer 0.10
[19:00] <Laney> psusi: 0.11 was a development release leading up to 1.0
[19:02] <Laney> 0.10 is EOL upstream even for bugfixes so we really should be pushing people off it
[19:09] <psusi> Laney: did 0.11 ABI break with .10?  Why didn't we ever upgrade to that?  why the jump to 1.0, skipping the version in between?
[19:10] <seb128> psusi, we did
[19:10] <seb128> psusi, 0.11 was the 1.0pre serie, as Laney said
[19:10] <seb128> psusi, e.g https://launchpad.net/ubuntu/+source/gstreamer1.0/0.11.94-1
[19:11] <seb128> psusi, oh, and yes, 1.0 (and 0.11) broke abi/api
[19:11] <seb128> they have been a multiple year refactoring effort
[19:13] <highvoltage> win 29
[19:14] <seb128> highvoltage, loose 30
[19:14] <highvoltage> story of my life.
[19:19] <seb128> cjwatson, I know you were TIL on mlocate, but it's a good idea to check the sponsoring queue in case before doing merges nowadays, https://code.launchpad.net/~logan/ubuntu/saucy/mlocate/0.26-1ubuntu1/+merge/169559 was waiting for sponsoring for some time
[19:25] <psusi> seb128: so upstream really screwed up by calling it 0.11 in the first place then?  it should have been 1.0?
[19:29] <Laney> psusi: Not really. It was always known to be the development series: http://gstreamer.freedesktop.org/releases/gstreamer/0.11.0.html
[19:29] <Laney> 0.10.x was maintained for ages
[19:34] <seb128> Laney, does GNOME screw by calling 3.<n> beta serie 3.<n-1>?
[19:34] <seb128> ups
[19:34] <seb128> psusi, ^
[19:34] <seb128> Laney, sorry ;-)
[19:45] <seb128> doko, I guess you didn't have a free slot for https://bugs.launchpad.net/ubuntu/+source/qtwebkit-opensource-src/+bug/1192567 today?
[19:45] <seb128> doko, do you think you will have time tomorrow? that's sort of blocking saucy work atm...
[19:47] <seb128> mterry, ^ sorry to bother you, but any chance you could help there?
[19:48] <seb128> mterry, those are non trivial, but didrocks reviewed pre-upload and was fine with it, he just didn't want to ack them because he was involved in the upload and we usually don't ack own uploads
[20:33] <slangasek> cjwatson: more partial upgrades out of update-manager today... libunity-core-6.0-6 and libunity-core-6.0-5 each have a strict versioned dep on unity-common, so the lib gets removed because of an unsatisfied dep, not because of breaks/replaces.  How should we handle this?
[20:33] <slangasek> cjwatson: I think I would argue there's nothing "common" about unity-common in this case...
[20:43] <slangasek> cjwatson: bug #1193120 filed for this, fwiw
[22:04] <bdmurray> hallyn: your patch in precise proposed for libcgroup is called libcgroup_sumlinked_bin.patch and you may have wanted to name it symlinked.  I'll reject it or approve it - your call.
[22:18] <doko> jbicha, are you sure the texinfo merge is correct?
[22:18] <doko> https://launchpadlibrarian.net/142958668/buildlog_ubuntu-saucy-i386.gcc-4.8-powerpc-cross_0.4_FAILEDTOBUILD.txt.gz
[22:19] <doko> at least it works in debian unstable
[22:51] <jbicha> doko: I believe I preserved the Ubuntu diff correctly but fixing that is well beyond my abilities
[22:56] <jbicha> oh it built correctly (which is why I didn't get a failure email) but your cross build didn't; I still don't know as I've never done cross-building
[23:57] <RAOF> @pilot in


[12:11] <excellproj> hi
 @excellproj [<excellproj> hi], Hello
[12:24] <excellproj> Need help. Have Lubuntu 18.10 (i386) https://imgur.com/a/pVNONzZ  The bottom of the window goes behind the bottom panel. How to fix it?
[12:25] <excellproj> Need help
 Please tell
 Did you check panel properties?
[12:29] <excellproj> need help
 @excellproj [<excellproj> Need help], is a bug, I'm not sure if the solution is already present in 19.04
 @HMollerCl [is a bug, I'm not sure if the solution is already present in 19.04], I don't have such problem in my system.
 🤔
 in case one of the Lubuntu gurus wants to help on this:
 https://askubuntu.com/questions/1120907/just-installed-lubuntu-18-10-on-a-macbook-pro-2010-a1278-right-click-on-touch
 touchpad 'right click' doesn't work for the user
[15:26] <sky_> hi
 @teward001 [touchpad 'right click' doesn't work for the user], wow! I didn't knew that existed. My first gues is that it is currently unsupported.
 @HMollerCl probably means someone on the Lubuntu team should add that to the list of requested features
 because Mac touchpads are junk :P
 (or rather, they don't have dedicated click buttons, the entire pad is a clicker)
 (and no specific left/right click buttons)
 yes, I need to be on bare metal to check it, now I'm on virtualbox
[15:38] <teward> @tsimonq2 ^ more work for y'all
 @teward001 [https://askubuntu.com/questions/1120907/just-installed-lubuntu-18-10-on-a-macboo …], 19.04 as well?
[16:07] <teward> @tsimonq2 you can ask them :P
 I didn't even know they had right click. What a cool new feature. Welcome to 2010, Apple.
[16:07] <teward> I'm assuming since it's an 18.10 question it's not a 19.04 one :p
[16:07] <teward> *salts @tsimonq2 for asking the wrong person*
[16:29] <wxl> @teward001: i think that askubuntu question is just a general libinput question
[16:29] <wxl> (or synaptics if you like the old stuff)
[16:30] <wxl> in fact, the linked question shows such a solution https://askubuntu.com/a/1029681


[15:44] <mdke> Rocket2DMn: I can't figure out that bug you are experiencing. I guess you are missing the symbolic link at /usr/share/gnome/help/libs?
[15:46] <Rocket2DMn> hey mdke
[15:46] <Rocket2DMn> i just ran across the bug report when i was triaging yesterday, and i was able to reproduce it
[15:46]  * mdke nods
[15:47] <Rocket2DMn> i didnt try to read very much into the output, let me have a look at the attachments i uploaded
[15:47] <mdke> Rocket2DMn: I've asked for the output of a couple more commands, if you have time
[15:48] <Rocket2DMn> sure let me wake up the laptop
[15:49] <Rocket2DMn> heh yeah that directory is empty
[15:49] <mdke> it exists?
[15:50] <mdke> it should be a symbolic link pointing at /usr/share/ubuntu-docs/libs
[15:50] <Rocket2DMn> i just posted back, the directory exists but it is empty
[15:51] <Rocket2DMn> negative, it is its own directory
[15:51] <mdke> how bizarre
[15:52] <mdke> I'm stumped about that
[15:52] <Rocket2DMn> that laptop has been upgraded since Feisty
[15:52] <mdke> aha...
[15:53] <Rocket2DMn> its always been to a stable release though, i dont use it for development testing
[15:53] <mdke> I think that in gutsy and feisty that directory may not have been a symbolic link, so I guess what has happened is that it didn't get removed, and therefore the symbolic link can't be created
[15:54] <Rocket2DMn> i see in Jaunty that it is a symlink
[15:54] <mdke> it should be in Intrepid too
[15:54] <Rocket2DMn> its not a symlink in hardy
[15:55] <mdke> does it have files in it in hardy?
[15:55] <Rocket2DMn> yeah
[15:55] <Rocket2DMn> they are symlinked though
[15:55] <mdke> ok, that must be the issue
[15:56] <mdke> i don't know how to fix that :)
[15:56] <Rocket2DMn> idk how updates are configured during upgrades, but i guess you need to run a command to check for a symlink, and if it doesnt exist, then delete the directory and create the link
[15:56] <Rocket2DMn> like a bash script with some if/then statements
[15:57] <mdke> maybe
[15:57] <Rocket2DMn> i dont actually patch bugs for Ubuntu, i drew the line at triaging
[15:58] <mdke> I'll ask one of the developers who knows all about packaging
[15:58] <Rocket2DMn> ok, do you want me to post the source of problem to the bug report?
[15:59] <mdke> thanks for your help debugging that issue
[15:59] <mdke> Rocket2DMn: no, that's fine. I think the bug report has the right info now
[15:59] <Rocket2DMn> ok, no problem
[15:59] <Rocket2DMn> and thank you for the testimonial last week
[15:59] <mdke> pleasure
[16:00] <Rocket2DMn> did you go to UDS Jaunty?
[16:00] <mdke> no
[16:00] <mdke> I've never been to a developer conference
[16:01] <Rocket2DMn> i havent either, but i would loved to have gone to this one.  I was from the Bay Area, and I have a friend who works at Google, I could've gotten in no problem
[16:01] <Rocket2DMn> didnt think my company would fly my 3k miles for that though
[16:02] <mdke> heh
[16:02] <mdke> I can't really see myself getting the time off either
[16:02] <Rocket2DMn> yeah same, woulda been great if they could fly me out there and give me a charge number
[16:03] <mdke> indeed
[16:03] <Rocket2DMn> apparently it was decided (or just announced) at UDS that the Forum Council can now approve Ubuntu Members
[16:03] <mdke> ok. I know it's been talked about for a bit
[16:04] <mdke> personally, I thoroughly disapprove of team councils being permitted to approve Ubuntu members, especially now that we have a great regional board system
[16:04] <mdke> if team councils do it, you lose the benefit of contributors being seen by other areas of the community, because teams just appoint members from their own section of the community
[16:05] <Rocket2DMn> yeah, I think the idea was that it could be granted to outstanding contributors to the forums.
[16:05] <Rocket2DMn> however i do wish the forums were more integrated with the rest of the community, and having to go to regional boards is one way to encourage that
[16:05] <mdke> that's exactly my point
[16:06] <Rocket2DMn> there is discussion right now about how another mod and i who are currently on the regional board application list are going to go through the approval process.  i'm all for staying with the regional board, like everybody else does
[16:06] <mdke> it's up to you :)
[16:07] <Rocket2DMn> we'll figure it out soon, it would be nice if they set a date for the next meeting though
[16:09] <j1mc> hi a
[16:09] <j1mc> all
[16:10] <Rocket2DMn> hello
[16:12] <j1mc> is there talk of a docteam meeting?
[16:12] <mdke> no :)
[16:13] <Rocket2DMn> lol, we dont actually have many people who sit in this channel, and those that do dont speak
[16:13] <j1mc> yes, it's pretty rare
[16:13] <mdke> I don't think we have had a meeting for a number of years now, it wouldn't be a bad idea
[16:14] <Rocket2DMn> i would very much like to know what duncan lithgow was doing onthe community docs and how we can clean it up
[16:16] <j1mc> i know that we had tried to coordinate a meeting during the hardy release, but couldn't work out schedules.
[16:17] <j1mc> it should be a busy doc cycle for me, as xfce needs new docs for xfce 4.6
[16:17] <mdke> cool
[16:17] <j1mc> fortunately, work has mellowed out some for now.
[16:17] <j1mc> so not as many late nights.
[16:18] <Rocket2DMn> hehe, thats good
[16:19]  * mdke ducks out for a bit
[16:19] <j1mc> have a good day, mdke
[16:19] <Rocket2DMn> see ya mdke
[16:19] <Rocket2DMn> hmm CategoryX and CategoryXwindowSystem


[03:24] <animeloe> hi there
[03:25] <animeloe> im having issues with booting 10.04 setver
[03:26] <animeloe> it freezes after the init-bottom finishes
[03:27] <animeloe> im running the latest ubuntu 10.04 kernel and updates
[03:29] <animeloe> any ideas how i can get it working again.  also trying to use the last kernel doesnt work either
[03:41] <kaushal> Hi
[03:48] <GamingX> Hey guys. Can someone help in installing Eclipse-PDT on Ubuntu ? I tried installing it from the tutorial here, but I'm having some problems with it https://help.ubuntu.com/community/EclipsePDT
[04:29] <mkonline> hi
[05:26] <kaushal> Hi
[05:26] <kaushal> Any clue about https://lists.ubuntu.com/archives/ubuntu-server/2011-December/006024.html ?
[08:47] <Vivek> I have made a fresh install of Ubuntu Ubuntu 11.10
[08:48] <Vivek> I have followed the following URL to install orchestra http://cloud.ubuntu.com/2011/09/oneiric-server-deploy-server-fleets-p1/
[08:50] <Vivek> When I do a cobbler list: I am not able to view the oneiric-i386  or  oneiric-x86_64 in any of the distros:, profiles:, repos:,  the mgmtclasses is completely empty.
[08:50] <Vivek> Why is this happening ?
[08:51] <Vivek> The Host is Ubuntu 11.10 and I am running orchrestra on a host running in virtualbox.
[09:22] <drt24> Vivek: you might need to run orchestra-$something to get it to initailise things properly
[09:23] <Vivek> What is the $something ?
[09:24] <Vivek> I am missing all oneric entries.
[09:30] <drt24> so if you do tab completion on orchestra- you should get a selection of different scripts to choose from I don't remember which the correct one was
[09:30] <drt24> potentially request isos or similar
[09:30] <drt24> (I don't have my VM with orchestra running at the moment)
[09:40] <Vivek> orchesta-import-isos
[09:40] <Vivek> drt24: orchesta-import-isos
[10:03] <drt24> ahh good :-)
[10:03] <lynxman> morning o/
[10:04] <jamespage> morning all
[10:04] <jamespage> morning lynxman
[10:06] <lynxman> jamespage: morning jamespage :)
[10:10] <caribou> morning
[10:11] <jamespage> Daviey, smoser, utlemming, lynxman (plus anyone else whos interested)
[10:11] <caribou> Question : when /boot is setup as a separate partition, is there a requirement for it to be ext2 ?
[10:11] <jamespage> the minimal virtual install is around +50MB oversized in precise ATM
[10:11] <lynxman> caribou: requirement is only put by grub, I think it supports XFS as well and other filesystems
[10:12] <caribou> thanks lynxman
[10:12] <jamespage> two versions of python is some of that; but we are also carrying multi-arch overhead - should/can this be disabled for the minimal-virtual install?
[10:12] <lynxman> caribou: "GRUB supports all commonly used Unix file systems, VFAT and NTFS used by Windows, as well as Logical Block Address (LBA) mode. GRUB allows users to view the contents of files on any supported file system."
[10:13] <caribou> I'm working on a kdump patch to fix an issue when /boot is a separate partition
[10:13] <caribou> lynxman: thanks, means that the patch will need to be more generic
[10:14] <lynxman> jamespage: I reckon so, but I think Daviey was doing some work on that
[10:21] <jamespage> lynxman, hmm - is Daviey around?  he might be on hols
[10:24] <Daviey> jamespage: o/
[10:24] <Daviey> holololowhat?
[10:26] <jamespage> Daviey: lynxman thought you might be looking at the minimal-virtual install size on amd64?
[10:26] <lynxman> jamespage: he's never on holidays :)
[10:26] <jamespage> its about 50MB oversize - see above
[10:29] <Daviey> jamespage: I don't know that we can disable multi-arch for a specific usecase
[10:30] <Daviey> we might just have to lump it, unless there are other reasons for the expansion?
[10:30] <jamespage> Daviey: well its only 50MB so I can update the test case to make an allowance for amd64 architectures
[10:30] <Daviey> I did notice am64 iso recently ballooned, not clear why
[10:30] <Daviey> (amd64 iso is currently oversized)
[10:30] <Daviey> .. so we do need to fix that.
[10:30] <jamespage> Daviey: OK - so I'll update the test case to account for the multiarch increase
[10:31] <jamespage> it will still fail; so I'll raise a bug as well
[10:31] <jamespage> I have looked but can't see why it is so much larger
[10:31] <Daviey> right
[10:31] <Daviey> I'd like to be certain that is the only reason for the bump
[10:31] <jamespage> +25MB for multiarch
[10:32] <Daviey> Out of interest, when was the last time anyone here used alien?
[10:36] <BigRedS> Daviey: three or four years ago I'd have thought. Back when it was relatively new, and most things were packaged for rpm
[10:41] <Daviey> BigRedS: right, we still ship it on the CD.. wonder if we still need to.
[11:01] <sarthor> where can i get help about openerp? I want to know can i install openerp on ubuntu-server as a server? will i be able to connected via my browser?
[11:05] <caribou> lynxman: looks like grub doesn't like XFS on /boot. my VM no longer boots :)
[11:05] <lynxman> caribou: *doh*
[11:05] <lynxman> caribou: it should supposedly work
[11:06] <caribou> well, grub-rescue tells me "unknown filesystem"
[11:06] <lynxman> :/
[11:19] <jamespage> Daviey: bug 904681
[11:19] <jamespage> I've also annotated the jenkins job with a link to this bug
[11:38] <Daviey> jamespage: you are pretty good.. aren't you?
[11:39] <Daviey> jamespage: I'm /certain/ there is a deeper problem
[11:48] <lynxman> Daviey: the ath9k rom in ipxe is still broken, should I try to build a package skipping it? :)
[11:48] <jamespage> Daviey: agreed
[12:02] <soren> jamespage: You don't log what packages are installed in those images, do you?
[12:02] <soren> jamespage: Like a package manifest of sorts?
[12:02] <jamespage> soren: well we grab the d-i syslog
[12:02] <soren> jamespage: i see the image size jumped 35 MB from 2011-11-29 to 2011-12-02.
[12:03] <soren> In VMBuilder, I used to run "dpkg-query -W --showformat='${Package} ${Version}\n'" at the end to capture the manifest.
[12:03] <soren> That was really useful in tracking down exactly like this.
[12:03] <jamespage> soren: that would be a good addition to the data captured
[12:06] <soren> Daily archive snapshots would also be awesome.
[12:19] <lynxman> Silly question but how can I change the Ubuntu install partition editor to create MBR partitions instead of GPT? I'm using old hardware
[12:27] <zul> lynxman: maybe in expert mode
[12:27] <lynxman> zul: hmm I'll try, thanks :)
[12:50] <koolhead11> hi all
[12:50] <lynxman> koolhead11: hi o/
[12:51] <koolhead11> hello lynxman . how are things :d
[12:52] <lynxman> koolhead11: busy :)
[12:53] <koolhead11> lynxman: awesome. i am reading OS. been a while i read hard copy of any book :P
[13:21] <RoyK> http://www.xkcd.com/989/ lol
[13:27] <koolhead11> hey RoyK i hate you man :P
[13:44] <BigRedS> If I've an md array rebuilding, is there a way to ask it which device is being readded?
[13:50] <Daviey> lynxman: how is it broken?
[14:17] <zul> Daviey: hey did you see the security review that jdstrand did for keystone?
[14:42] <Daviey> zul: sure did
[14:42] <zul> Daviey: will put it on my list
[14:43] <Daviey> \o/
[14:43] <zul> so its going to be properiatary (i cant spell that word)
[14:49] <lynxman> Daviey: the same rom as before doesn't work
[14:50] <lynxman> Daviey: ath9k rom is broken, and nobody knows on #ipxe
[14:53] <lynxman> Daviey: I think I'll just exclude ath9k rom or maybe use the old one
[17:25] <hallyn> kees: jjohansen: the seccomp2 stuff in ubuntu-precise kernel is supposed to be usable, right?
[17:25]  * hallyn fixin' to have some fun with seccom2+lxc over break
[17:28] <kees> hallyn: I still haven't examined the execness, but the code is there in precise, yes.
[17:28] <kees> hallyn: I'll be excited to see what you come up with!
[17:29] <hallyn> kees: cool, thanks.  First I'll actually play with the mini jail from google folks, so I'll verify with that whether the kernel is all right I  guess :)
[17:32] <kees> hallyn: yeah, minijail is cool
[17:35] <zul> adam_g: can you have a look http://paste.ubuntu.com/771266/
[17:38] <adam_g> zul: is this to be the current delta between our branch and the ubuntu-openstack-packagers branch?
[17:38] <zul> adam_g: yeah plus my fixes to it
[17:42] <adam_g> zul: ah, looks good. i wanna check on "glance-manage db sync", im not sure if that command is still there.. even if it is, "glance-manage" wasn't functioning at all last night. im not sure if config files need updating or what
[17:43] <zul> i installed that package this morning and didnt have the same problem
[17:43] <adam_g> hmm ok
[17:48] <smoser> adam_g, have you installed precise packagess of current nova?
[17:48] <smoser> i was seeing db sync issues with nova on devstack yesterday (from git, not packaged)
[17:48] <adam_g> zul: is there a branch somewhere with that diff? ill give it a go
[17:48] <zul> adam_g: not yet gimme a sec
[17:48] <adam_g> smoser: i haven't used anything that hasn't been in our archive this cycle. ill probably start working off milestone-proposed now
[17:49] <adam_g> smoser: what was the issue? tables already exist?
[17:49] <smoser> so... if someone could veirfy that nova db sync works on precise from package, that'd be good.
[17:49] <smoser> adam_g, hold on. let me dig log.
[17:49] <zul> adam_g: lp:~zulcss/glance/ubuntu-merg
[17:49] <zul> smoser: hmmm?
[17:49] <adam_g> smoser: ive been using packaged nova without problems
[17:50] <smoser> but what level are they at?
[17:50] <smoser> this is recent in last week i think
[17:50] <smoser> http://paste.ubuntu.com/770272/
[17:51] <smoser> now, clearly devstack does all that pip crap, so something else could be in the way. but i just hoped someone had seen it functionoing given recent nova on recent precise.
[17:51] <smoser> that was tip of both yesterday morning.
[17:51] <adam_g> smoser: ive seen that before a while ago, it was a bad migration config in nova's migrate repo
[17:51] <smoser> adam_g, well it woekd on oneiric
[17:52] <smoser> 85% sure they were the same things
[17:52] <adam_g> smoser: the same nova versions?
[17:53] <smoser> yeah.
[17:53] <smoser> both at tip of af54e79b7815c233c6e800bc79e428fe23f92eb7
[17:55] <adam_g> smoser: it might be related to mysql changes. i hit almost the exact same thing (if i remember correctly) only when mysql was configured using InnoDB instead of MyISAM
[17:55] <smoser> adam_g, i just launched another one in canonistack.
[17:55] <smoser> i just launch with: http://paste.ubuntu.com/771386/
[17:56] <smoser> as user-data on  my precise amis
[17:56] <adam_g> smoser: https://bugs.launchpad.net/nova/+bug/816236
[17:57] <smoser> if this reproduces now i'll open a bug, adam_g
[17:57] <smoser> and you can poke at the system too
[17:58] <adam_g> smoser: at the surface it looks like the same thing, id look at the patch that fixed that bug and see if the same could be applied to the migration thats failing. it might be triggered by our mysql changes, but ideally those migrations should run on any compatable db backend, id think
[18:17] <adam_g> zul: that package doesn't work. none of of the dependencies i added in lp:~gandelman-a/glance/fixdeps exist in that pkg branch?
[18:18] <zul> adam_g: shit gimme a sec
[18:18] <zul> i totally forgot about your branch in my branch
[18:19] <adam_g> :)
[18:21] <zul> adam_g: fixed
[18:23] <adam_g> zul: im curious to know why we're not doing all of this ontop of the upstream branch?
[18:24] <zul> adam_g: becuse i have pushed to the upstream branch
[18:24] <zul> i wanted someone to test it other than me before i pushed it
[18:24] <zul> s/pushed it/merge request/g
[18:25] <zul> but after those changes we will be sync for glance at least
[18:25]  * zul goes back to writing man pages
[18:26] <adam_g> zul: well i mean, why not rebase based on what is in the current upstream branch, add our changes and push back? that dependency change you just applied will be a merge conflict against the upstream change
[18:27] <zul> adam_g: thats the goal essentially
[18:27] <adam_g> zul: ah, im not tryin to bust your chops just trying to wrap my head around how this is supposed to work :)
[18:28] <zul> adam_g: sure sure, but yes we need to sync everything up
[18:28] <adam_g> zul: goin to #openstack-packaging
[18:37] <broder> zul: what's your intent with the branches owned by ~openstack-ubuntu-packagers? my best interpretation of the intent is that changes should go there instead of the lp:ubuntu/* branches, but there's no Vcs-Bzr tag in the packaging to confirm that
[18:39] <zul> broder: openstack-ubuntu-packagers is apart of the openstack project and thats where they keep their packaging, ubuntu packaing is kept in ubuntu-server-dev and the debian/control needs to be updated to reflect this
[18:40] <EvilResistance> perhaps you all can help me...  i've got a system which tries to boot, but yells about a readonly filesystem and says it needs recovery (after which writing will become active again).  It dumps me into an initramfs prompt.  If I use a LiveCD to fsck the partition, will that fix the issue?
[18:47] <EvilResistance> nevermind fixed it
[18:47] <EvilResistance> running the fsck fixed the partition.
[19:09] <zul> adam_g: is it ok for merging?
[19:19] <adam_g> zul: crap hold on
[19:22] <webPragmatist>  /usr/sbin/service: 9: Syntax error: EOF in backquote substitution
[19:22] <webPragmatist> can i reinstall the service binary somehow?
[19:25] <smoser> webPragmatist, sudo apt-get install --reinstall sysvinit-utils
[19:30] <webPragmatist> smoser: what's up with this UUID=08f80e21-4bc5-4192-b77e-fe4c476c62b3 /               ext4    errors=remount-ro 0       1
[19:31] <webPragmatist> should i restart?
[19:31] <webPragmatist>  man this server is effed
[19:33] <adam_g> SpamapS: ping
[19:33] <smoser> webPragmatist, i dont know what you mean.
[19:33] <smoser> that looks sane to me.
[19:33] <SpamapS> adam_g: pong, sup?
[19:35] <adam_g> SpamapS: mysql on precise, did the default storage engine change?
[19:36] <webPragmatist> smoser: the drive is mounted read-only ?
[19:36] <webPragmatist> i'm just confused… maybe it needs to run fsck?
[19:36] <SpamapS> adam_g: yes!
[19:36] <SpamapS> adam_g: 5.5 has InnoDB by default.
[19:37] <SpamapS> because MyISAM is doomed. :)
[19:37] <smoser> webPragmatist, thats from fstab? its just telling you that if there are errors, it will be remounted read-only.
[19:37] <smoser> so, if it is RO, then there might have been issues on fscheck.
[19:38] <adam_g> SpamapS: ok, thats what i figured. thanks
[19:38] <adam_g> smoser: ^^ thats why this is only turning up on precise
[19:40] <smoser> hm..
[19:40] <SpamapS> nova can't handle being innodb?
[19:41] <smoser> adam_g, so you tihnk that 022_ migrates from InnoDB -> InnoDB and that causes issues ?
[19:41] <adam_g> SpamapS: it can with special care during migrations.
[19:43] <adam_g> smoser: probably, or a python-migrate not being able ot handle storage engines being swapped out from under it
[19:44] <SpamapS> alter table foo engine=InnoDB; when it already is InnoDB is exacty the same as doing 'optimize table foo'
[20:24] <webPragmatist> smoser: what should i do heh?
[20:31] <sveinse> I'm setting up RAID5 md on 4 disks. Is it recommended to put LVM on top of the md? I have no need for more than one partition in this md. And I doubt the server will grow as its full.
[20:49] <SpamapS> sveinse: LVM has other benefits
[20:49] <SpamapS> sveinse: like snapshots
[21:15] <zul> adam_g Daviey: so that glance-manaage bug doesnt affect the milestone-proposed branch (just tested it) so we should be ok
[21:17] <Daviey> win
[21:18] <Daviey> smoser: How did daily triage go?
[21:19] <smoser> ;)
[21:19] <Nafallo> hah! nice answer :-P
[21:21]  * Daviey does some
[21:28] <Daviey> Anyone fancy sponsoring, bug 903901 SRU?
[21:29] <smoser> i'm looking at it Daviey
[21:29] <Daviey> rocking!
[21:29] <smoser> i hate the package importer failing
[21:31] <Daviey> I hate disease, poverty and lack of world peace; we all have things we don't like, eh? :)
[21:31] <smoser> disease.
[21:31] <smoser> pft
[21:31] <guntbert> says the young and healthy
[21:32] <SpamapS> zul: were you going to respond to kees question about SRU's ?
[21:32] <zul> SpamapS: i did
[21:32] <SpamapS> stupid sup..
[21:32]  * SpamapS digs back through archived threads
[21:33] <SpamapS> zul: you  must have responded in private
[21:33] <Daviey> I didn't see the reponse, i don't thik
[21:34] <Daviey> oh, wait - i did
[21:34] <SpamapS> the list didn't show it
[21:34] <zul> SpamapS: stuck in the moderation queue again i bet
[21:35] <Daviey> Yep.. zul - you'll need to poke sabdfl, mdz, Keybuk, cjwatson or pitti.
[21:35] <SpamapS> Or join the ML
[21:35] <Daviey> Hmm, not necessarily in that order.
[21:35] <zul> lovely
[21:36] <SpamapS> its only moderated for non-subscribers isn't it?
[21:36] <Daviey> I assumed the subscribers was limited to the techboard, by design.
[21:36] <Daviey> But i guess there is no reason for it to be.
[21:36] <SpamapS> nope, I'm subscribed
[21:36] <zul> so much to do so little time
[21:37]  * Daviey sub's
[22:04] <wmp> http://wstaw.org/m/2011/12/15/plasma-desktopLb1917.jpg - anyone know what is wrong?
[22:13] <SpamapS> wmp: "Root-NFS: no NFS server address"
[22:14] <SpamapS> wmp: that may be misleading, but basically it means the server wasn't able to mount the root partition
[22:14] <wmp> this have all kernels, but only on this machne dont work
[22:14] <SpamapS> wmp: in grub, what does 'root=' show ?
[22:14] <wmp> SpamapS: wait ;)
[22:17] <adam_g> zul: what release did you test?
[22:18] <wmp> SpamapS: http://wklej.org/id/648592/
[22:21] <zul> adam_g: you are using trunk (e3), release is (e2)
[22:21] <zul> adam_g: i updated my branch so you should be able to just pull it
[22:21] <zul> and rebuild yadda yadda
[22:22] <adam_g> ok
[22:23] <SpamapS> wmp: hm, I don't really know how to read that.. but typically I'd expect an 'initrd' somewhere
[22:29] <wmp> SpamapS: i must change sda1 to hda1
[22:29] <wmp> interesting...
[22:44] <sanderlt> Heyo everybody! i need to get to (whole) bash terminal from gdm.. any suggestions?
[22:48] <SpamapS> sanderlt: ctrl-alt-f1
[23:00] <adam_g> zul: that pkg seems to be cool excpet for registry


[02:14] <roaksoax> bigjools: can you please verify thebbugs forndjango
[02:25] <bigjools> roaksoax: I think you need to type that again
[02:59] <AskUbuntu> logging problem with juju bootstrap | http://askubuntu.com/q/221979
[03:31] <roaksoax> bigjools: SRU's for django need to be verified ;)
[03:41] <bigjools> roaksoax: I'll take a look soon
[03:45] <roaksoax> bigjools: thank you
[06:09] <shang> anyone know if maas can handle customized images?
[06:14] <bigjools> shang: you could replace the default images, but there's no official support
[06:14] <shang> bigjools: right, that's my understanding too. Is it on the roadmap by any chance?
[06:15] <bigjools> shang: not any immediate roadmap, no
[06:15] <shang> bigjools: got it. thanks
[06:15] <bigjools> we'd certainly take patches to do that :)
[06:36] <shang> :-D
[15:22] <roaksoax> allenap: do you happen to know what the ip-context patch for python-txtftp does (as it what it fixes, and how to test it to get the SRU done) bug #1068843
[15:27] <allenap> roaksoax: It enables the backend code know what address a request came in on. The upstream pull request is https://github.com/shylent/python-tx-tftp/pull/10. The tests in the patch demonstrate that it's doing the right thing. In practice, we've QAed it in MAAS.
[15:37] <roaksoax> allenap: ok cool. But for SRU we need to be able to reproduce the bug before/after the fix
[15:37] <roaksoax> allenap: is there a way to do so?
[15:38] <allenap> roaksoax: Mmm. Try running a MAAS cluster on the old version? I could code something up to demonstrate it, if that's essential.
[15:39] <roaksoax> allenap: no not necessary, we only need a way to ensure the patch fixes the bug, as in 1. run maas, 2. do this command 3. if the bug still continues X happen, if not Y happen
[15:49] <allenap> roaksoax: A coarse demonstration might be: set up MAAS with a cluster on a machine other than the region's machine. Ensure that iscsi is off on the region's machine. Boot a new machine (so that it attempts to enlist) and watch the boot fail because it tries to iscsi mount from the region's machine instead of the cluster's machine.
[15:53] <roaksoax> allenap: ok cool
[15:53] <roaksoax> allenap: thanks for the info
[15:53] <allenap> roaksoax: Let me know if you need something smaller.
[16:41] <roaksoax> Daviey: howdy! When you have the time could you please process python-tx-tftp from the SRU queue for quantal?
[16:42] <Daviey> roaksoax: okay
[16:44] <roaksoax> Daviey: thank you :)
[23:57] <Lennie_> hi
[23:58] <Lennie_> I'm trying to install my first node with MAAS, but it doesn't seem to work
[23:58] <Lennie_> it downloads something from tftp and talks with HTTP to localhost, but it doesn't do anything useful