[00:53] <petersfreeman> I'm having difficulty connecting to my printer.  I set up a USB connected printer attached to my print server using CUPS.  From my desktop,  I let it find the printer connected to the server (Server and Desktop are on the same LAN).  I can print a test page from CUPS connected to the server (192.168.0.xx:631, but I cannot print a test page from CUPS connected to my desktop (localhost:631).  Ideas?
[00:59] <sarnold> check cups logs on both systems?
[02:05] <petersfreeman> Sarnold:  got it working.  Thaks
[02:05] <sarnold> petersfreeman: nice, what was it?
[03:02] <Demon_Jester> Hey guys, I am in a situation hopefully you can help me. So for some reason I decided to make my boot partition 400gb. I am wanting to move that 400gb of free space from sda1 to sda6, is there a way for me to do that? or what would I have to do.
[05:49] <DeadVillain> hello all
[06:46] <ikonia> win 6
[08:11] <lordievader> Good morning.
[12:06] <mdeslaur> dannf: I'm going to release security updates for mysql, can you confirm that the packages in -proposed are all tested?
[12:08] <mdeslaur> dannf: also, since we always ship the latest upstream mysql, I'm not sure how we're supposed to maintain those patches...have they been submitted upstream?
[12:09] <bekks> They are proposed and not yet finally tested. If they are tested fully. They are moved out of proposed.
[12:57] <kevin070982> hi there
[12:57] <kevin070982> need help for ubuntu server
[12:58] <kevin070982> our Raid1 sytem failed to start after a power loose in our place
[13:03] <kevin070982> anybody here?
[13:06] <rbasak> !patience
[13:07] <kevin070982> no boot paste.ubuntu.com
[13:08] <rbasak> You might want to state your actual problem though. Volunteers tend not to want to commit to helping someone with open ended problems because they tend to take an open ended amount of time.
[13:08] <kevin070982> no boot http://paste.ubuntu.com/11887633/
[13:08] <kevin070982> softraid
[13:27] <lordievader> kevin070982: Did you boot a live stick, is your data still there?
[13:33] <kevin070982> i will boot via live stick in few minutes
[13:33] <kevin070982> still downloading one
[13:33] <kevin070982> the question is what is the best way to make the raid work again
[13:33] <kevin070982> seems to me that the bootloader didn^t load the raid partition
[13:36] <lordievader> First see if the data is still there. See what the damage is.
[13:47] <dannf> mdeslaur: the only thing that still needs testing is the trusty update, which FTBFS due to an unrelated issue. there's a fix for that in the sru queue.
[13:48] <dannf> mdeslaur: oracle is looking at fixing it - they can't take my fix because it's a port from mariadb that wasn't contributed under the OCA (noted in the dep3)
[13:49] <dannf> mdeslaur: trusty mysql-5.5 is good, mysql-5.6 is the one in the SRU queue
[13:52] <mdeslaur> dannf: all I care about is mysql-5.5/trusty, mysql-5.5/utopic and mysql-5.6/vivid
[13:52] <mdeslaur> dannf: are those tested?
[13:52] <dannf> mdeslaur: yes they are
[13:54] <rbasak> o/
[13:54] <rbasak> dannf: http://paste.ubuntu.com/11887850/ to catch up from #ubuntu-hardened
[13:55] <rbasak> (sorry I didn't notice this concurrent conversation)
[13:55] <mdeslaur> dannf: so I wasn't part of the original discussion with regards to those patches...I added my concerns to the bug
[13:55] <mdeslaur> but rbasak has now told me it's been discussed
[13:56] <mdeslaur> dannf: so my understanding is that if I prepare a new mysql version and the patches don't apply I just ignore them?
[13:57] <dannf> mdeslaur: that would cause memory corruption for ppc64el/arm64 users
[13:57] <mdeslaur> of course, that is likely to regress users who think mysql is usable in trusty
[13:57] <dannf> so i don't think ignoring them is a good approach
[13:57] <mdeslaur> dannf: right, so are you commiting to getting me updated and tested patches for each new mysql release as soon as it comes out?
[13:58] <rbasak> My understanding was that if dannf's team can't fix it, then we wouldn't hold up a security update for the other archs.
[13:58] <mdeslaur> I can't selectively publish archs
[13:58] <mdeslaur> unless it FTBFS
[13:58] <rbasak> Right, so that would mean regressing arm64 etc.
[13:59] <mdeslaur> rbasak, dannf: if the patches do appear to apply, and it builds, do I release the new version without testing on ppc64el and arm64?
[14:00] <rbasak> I'd say yes.
[14:00] <dannf> mdeslaur: to the extent reasonable, yes (i commit to updating), but that does need some time
[14:00] <rbasak> Again, I apologise for not speaking to you before. I don't want to see this as a done thing - if that doesn't work for you, we should speak and reconsider.
[14:00] <dannf> mdeslaur, rbasak +1 - if it applies, go for it
[14:02]  * dannf understands this is a bad situation - wish i could do more, but nothing i can personally do since i don't hold copyright on the fix
[14:02] <dannf> but i can poke oracle again and ask about status
[14:03] <rbasak> I wonder if we should reconsider Oracle MySQL's place in main on the basis of this issue.
[14:04] <rbasak> On one hand the patch author won't sign Oracle's agreement, but on the other hand it's Oracle that won't take the patch and haven't fixed the bug.
[14:04] <rbasak> Combined with them not providing security patches.
[14:05] <mdeslaur> rbasak: while that's a good discussion for the dev release, it doesn't change anything with regards to the stable releases that I have to update in the next couple of days
[14:05] <rbasak> mdeslaur: understood. If you're still unhappy, I think we should reconsider carrying the patch.
[14:06] <mdeslaur> adding these patches to trusty means every three months for the next 4 years the patches need to get rebased and tested on the latest mysql version
[14:07] <dannf> mdeslaur: until oracle releases an update with a proper fix, yeah - which they are working on
[14:07] <mdeslaur> right
[14:08] <mdeslaur> ok, so here's the plan: 1- rbasak please find someone in the sru team to release the packages currently in -proposed ( mysql-5.5/trusty, mysql-5.5/utopic and mysql-5.6/vivid)
[14:08] <mdeslaur> either today or tomorrow
[14:09] <mdeslaur> that way, those will be available for ppc64el nd arm64
[14:09] <mdeslaur> I will prepare updates for the new versions with the patches
[14:09] <mdeslaur> If they apply, fine, if they don't, I'll ping dannf
[14:10] <mdeslaur> I may publish the updates anyway, just not for the two archs that FTBFS
[14:10] <dannf> mdeslaur: can you point me at the new release/patches/whatever, so i can look at the risk ahead of time?
[14:10] <mdeslaur> depending if dannf can quickly get me updated patches
[14:10] <mdeslaur> dannf: that would be the 5.5.44 and 5.6.25 new upstream versions from mysql's site
[14:10] <dannf> rbasak: arges approved the srus, i can ask if he'll flush -proposed for us
[14:11] <rbasak> OK. I'd like to delegate chasing the SRU team to dannf, if dannf you're OK with that.
[14:11] <rbasak> Though, this assumes that mdeslaur you're happy with this situation.
[14:11] <rbasak> If you're not and think we should reconsider carrying the patches in the first place, then we should do that before releasing the SRUs.
[14:11] <mdeslaur> well, I can't say I'm happy with the situation...this definitely makes things more complicated, and has a chance of regression users of those archs
[14:12] <mdeslaur> but if those archs are broken anyway...
[14:14] <mdeslaur> if dannf and/or his team are willing to drop everything when a security notice is published to get the patches working for a new version within a day or two, then that's fine
[14:15] <rbasak> I take the view that the patches can't be allowed to hold up security updates for the other architectures, and nor can we expect mdeslaur's team to fix it.
[14:15] <rbasak> So that means dannf's team gets the opportunity to fix it when necessary, or if not, then the affected architectures regress.
[14:15] <dannf> i can't commit anyone else from my team - but, unless i'm unreachable, i can commit myself to that
[14:16] <Luke> hey guys, I have a service i'm making that can have multiple instances running on the same box. how should i represent that in systemd?
[14:16] <rbasak> Luke: http://0pointer.de/blog/projects/instances.html
[14:17] <Luke> rbasak: wow thanks
[14:17] <Luke> that was fast
[14:17] <Luke> rbasak: I hope this wasn't the first google result ;-P
[14:17] <rbasak> Luke: https://encrypted.google.com/search?hl=en&q=systemd%20multiple%20units
[14:17] <Luke> haha
[14:17] <rbasak> But you do need to know what terms to Google for :)
[14:17] <mdeslaur> rbasak, dannf: ok, so we're on the same page?
[14:17] <Luke> i didn't think "instance" was the right word
[14:18] <dannf> it would be nice if we had a way to at least not release broken builds on those archs in the situation that we can't. i'd hate to knowingly release broken builds to someone's stable environment
[14:18] <Luke> rbasak: instance brings up the same first result /me is embarrassed
[14:18] <Luke> ty
[14:19] <rbasak> dannf: I suppose the patches could FTBFS and then users will be held back on that arch. But we'd need to check what the Arch: all packages do in terms of versioned dependencies.
[14:19] <mdeslaur> dannf: is there a quilt trick to get it to apply the arch specific patches to see?
[14:19] <mdeslaur> rbasak: oh, argh, I didn't think about the Arch: all
[14:19] <rbasak> dannf: but that also means that affected arches will never get a security update. So which is worse?
[14:20] <dannf> mdeslaur: ln -s debian/patches/arch-specific/patches-arm64 patches-amd64
[14:20] <dannf> rbasak: tough to say in general - one is definitely going to break them though, the other (security) is status quo
[14:21] <dannf> but security could certainly be worse in some situations of course
[14:21] <dannf> and w/ mysql, we don't really know what the security issues are :(
[14:21] <rbasak> Maybe the fact that we're considering this should mean that we shouldn't carry the patch and consider MySQL broken on the affected arches until an upstream fix arrives.
[14:22] <rbasak> I'm seriously reconsidering my position here.
[14:22] <dannf> rbasak: that feels like we're saying x86 is more supported than other archs, which isn't what we communicate
[14:23] <mdeslaur> it's quite unfortunate that this is with the mysql package...pretty much any other package in the archive where we can backport security fixes this wouldn't have been an issue
[14:23] <dannf> if there was corruption in an LTS main package on x86, wouldn't we carry a patch?
[14:23] <rbasak> dannf: I feel like we're saying that in the case of Oracle MySQL, upstream policies mean that for us to keep it in main arches are supported only as well as upstream support them.
[14:24] <rbasak> dannf: for src:mysql-*, I'm not sure, because of upstream policies it's a special case.
[14:24] <rbasak> It only remains in main because upstream has a good track record on this (until now).
[14:24] <rbasak> http://www.ubuntu.com/about/about-ubuntu/conduct - "We expect participants in the project to resolve disagreements constructively. When they cannot, we escalate the matter to structures with designated leaders to arbitrate and provide clarity and direction."
[14:25] <rbasak> I'm tempted to say that we're getting to the point where we need a TB decision in order to be decisive.
[14:25]  * dannf feels like we have a working model (dannf will port) and a backup plan (will drop patches) - i don't see why dropping those patches would be better, unless there's no reasonable grace period to give me to port
[14:26] <dannf> counter argument is that right now we don't have working packages on those archs - but i don't know that that is obvious to any users. the builds are there.
[14:26] <dannf> they will just secretly eat your data
[14:26] <mdeslaur> right, that is why I'm conflicted
[14:27] <rbasak> 1) I don't like the bus factor in that. I feel that we should have a team commitment to port the patches.
[14:28] <rbasak> 2) Falling back to the backup plan means regressing users, who might elect to use an alternative if they know in advance, rather than receiving a regression. So the existence (and need for) the backup plan gives me doubt. Are the chances of needing it great enough that we shouldn't consider builds on these arches to be usable?
[14:28] <dannf> i'm sure we can get others on my team to commit to the raw porting - my only concern is w/ the actual packaging
[14:30] <mdeslaur> dannf: ideally someone on your team would maintain a tested PPA for each new upstream version of mysql with the patches applied, and tested
[14:30] <dannf> and i should be open to my potential conflict of interest - i'm paid to support arm64 customers who want to deploy this
[14:30] <mdeslaur> so when oracle's quarterly security advisory goes out, I can pluck the updated patches out of the PPA
[14:31] <dannf> mdeslaur: that seems reasonable
[14:32] <rbasak> Aren't a significant proportion of upstream releases from security advisories (ie. not available earlier)?
[14:32] <mdeslaur> seems to me they come out earlier than the security advisories
[14:32] <mdeslaur> I'm trying to find that out now
[14:33] <rbasak> Even though we had the MRE approved, I've not had the time to keep up to date with new upstream releases.
[14:33] <mdeslaur> 5.5.44 came out on 2015-05-29
[14:33] <mdeslaur> and they published the security advisory for it this week
[14:33] <dannf> is there an announce list for new releases?
[14:34] <rbasak> Ah, so they release first and then tell people what security fixes (if any) were in it six weeks later? I didn't realise that.
[14:35] <rbasak> If that's true then it seems to me that if we did keep up with the MREs then you'd just need to pocket copy to -security
[14:35] <mdeslaur> I'd have to rebuild in -security
[14:36] <rbasak> Ah, OK
[14:36] <rbasak> So...does this mean that dannf's team will do the MREs for us? :)
[14:36] <mdeslaur> heh
[14:37] <mdeslaur> IT'S A TRAP!
[14:37] <mdeslaur> ;)
[14:37] <rbasak> :)
[14:37] <rbasak> It does seem like the logical conclusion though!
[14:38] <mdeslaur> dannf: sorry for making this seem complicated, but this sort of thing has happened before...and while everyone has good intentions, at some point down the road when code gets refactored, nobody has time to do the work anymore
[14:39] <mdeslaur> and that's when we're stuck with the hard decision
[14:39] <mdeslaur> so I just want to make sure we're on the same page if it comes to that and we do need to regress our users
[14:39] <dannf> mdeslaur: right, part of our agreement here was to make sure we had a long term plan - i.e., oracle will care/provide a fix. we have that commitment, but no ETA
[14:39] <mdeslaur> oh, that's good news
[14:40] <dannf> we've got them hw to test with, etc - we're poking them about status today
[14:41] <mdeslaur> ok, I wasn't aware that there was a commitment there...that definitely alleviates my concern a bit to know that these could possibly be upstream in the next few versions
[14:43] <dannf> as for us doing MREs - i don't think that's necessarily a bad idea for this period. of course, if builds/tests fail for unrelated reasons, that's something we'd need help with
[14:44] <dannf> though i'm still not sure on how to get informed about a new release
[14:44] <rbasak> I'd expect my team to help with anything MRE related, though priority would be up to my manager.
[14:44] <rbasak> (and thus time)
[14:44] <mdeslaur> ok, so the patches do apply to the new 5.5 and 5.6
[14:44] <rbasak> As for being informed about a new release, I don't really know either.
[14:45] <rbasak> Perhaps we should set something up to watch uscan.
[14:45] <rbasak> That'd be useful for other packages too.
[14:45] <mdeslaur> yeah, or script something to monitor dev.mysql.com
[14:45] <mdeslaur> perhaps there's a mailing list, I'm not sure
[14:46] <dannf> i can ask oracle
[14:49] <dannf> rbasak: mdeslaur: at this point, are you both ok w/ me asking sru-team to push those updates out?
[14:49] <rbasak> dannf: I wonder if it's an idea to write out what we've agreed first to make sure that everyone is in agreement?
[14:50] <mdeslaur> yeah, adding a comment to the bug to state what we've agreed would be ideal
[14:50] <mdeslaur> once we've stated it here
[14:50] <rbasak> Maybe start in a pad to avoid confusing updates in the bug.
[14:51] <mdeslaur> right
[14:51] <dannf> sure. 1) dannf's team will figure out how to be notified of micro releases and maintain a ppa of test builds that we use to validate on arm64
[14:51] <dannf> oh, pad is fine
[14:52] <mdeslaur> rbasak: do you have a pad?
[14:53] <rbasak> mdeslaur, dannf: http://pad.ubuntu.com/mysql-arm64-corruption-patch
[14:53] <rbasak> (I just created it)
[14:56]  * rbasak wonders why everyone is a shade of pink today
[14:58] <dannf> btw, i'll run this by my manager this morning to make sure we can deal w/ the bus factor
[14:58] <dannf> mdeslaur, rbasak and are these updates always quarterly?
[14:58] <mdeslaur> dannf: the security notices are quarterly
[14:58] <mdeslaur> dannf: the mysql updates happen at any time I believe
[14:59] <mdeslaur> ie: there can be 2 updates between security notices
[14:59] <dannf> ok
[14:59] <mdeslaur> so you can plan when you're going to update your PPA, as long as it's done before the security notice is published, which is usually at a pre-determined date
[14:59] <mdeslaur> does that make sense?
[15:00] <dannf> mdeslaur: yes. is there a security notice list, or should i ask oracle about that too?
[15:00] <mdeslaur> dannf: http://www.oracle.com/technetwork/topics/security/alerts-086861.html
[15:00] <mdeslaur> the dates, and the notices are listed there
[15:00] <mdeslaur> no next date is 20 October 2015
[15:01] <rbasak> So arm64/ppc64el users are at some risk of regression as it's not an upstream patch. Should we release note this?
[15:01] <rbasak> (although of course it's going into Trusty too, for which release notes are already published)
[15:02] <mdeslaur> dannf: so _if_ a new version is published at the same time as the security notice (I don't think that happens), is a 2 day delay enough?
[15:03] <mdeslaur> rbasak: hrm, is changelog not enough?
[15:03] <mdeslaur> rbasak: not sure where else to put it
[15:04] <rbasak> mdeslaur: changelog will have to do I guess. My thought is to inform users of the risk _before_ it happens.
[15:04] <rbasak> (as it might affect DB or platform choice)
[15:04] <mdeslaur> rbasak: if we do have to drop the patches, we can add a notice to the USN text
[15:04] <rbasak> That would certainly be useful.
[15:05] <dannf> mdeslaur: i suspect a 2 *working day* delay would be enough
[15:05] <mdeslaur> rbasak: ok, added to pad
[15:05] <mdeslaur> dannf: ah, right, that's what I meant, I'll clarify
[15:09] <mdeslaur> I'm satisfied, are you rbasak, dannf?
[15:09] <dannf> +1
[15:09] <rbasak> +1
[15:09] <mdeslaur> awesome
[15:10] <mdeslaur> I'll add the info to the bug
[15:10] <jdstrand> I'm sorry I was in a meeting
[15:10] <mdeslaur> dannf: is the mention of your commitment from oracle in the pad an issue?
[15:10] <dannf> mdeslaur: let me confirm w/ my manager first, if that's ok - should be within this hour
[15:10] <jdstrand> can someone tell me why the patches aren't upstreamable? certainly, upstream would want these to work well on those archs?
[15:10] <jdstrand> (speaking of mysql)
[15:10] <mdeslaur> dannf: yes, definitely
[15:10] <rbasak> jdstrand: the patch author declines to sign Oracle's agreement.
[15:10] <jdstrand> who is the patch author?
[15:11] <dannf> jdstrand: mariadb devs
[15:11] <jdstrand> meh
[15:11] <mdeslaur> jdstrand: it's a licensing issue, but dannf's team does have a commitment from Oracle to fix the issue themselves
[15:11] <jdstrand> is there an upstream bug with mysql so they can clean room patch it?
[15:11] <jdstrand> ok
[15:11] <mdeslaur> jdstrand: yes, there's a bug
[15:11] <rbasak> http://bugs.mysql.com/bug.php?id=76135
[15:11] <jdstrand> so this situation is 'temporary'
[15:11] <dannf> jdstrand: yes, and they have engaged - but i don't know the status, we're asking today
[15:12] <jdstrand> alright, whatever you've come up with between you and mdeslaur is fine with me
[15:12] <mdeslaur> jdstrand: are you ok with what's in the pad?
[15:12] <jdstrand> I just wasn't clear on that point
[15:12] <jdstrand> can you paste the link?
[15:12] <mdeslaur> jdstrand: http://pad.ubuntu.com/mysql-arm64-corruption-patch
[15:12] <rbasak> http://pad.ubuntu.com/mysql-arm64-corruption-patch
[15:12] <mdeslaur> http://pad.ubuntu.com/mysql-arm64-corruption-patch
[15:12]  * jdstrand reads
[15:12] <rbasak> Did you get that?
[15:13] <rbasak> It's http://pad.ubuntu.com/mysql-arm64-corruption-patch :-P
[15:13] <mdeslaur> hehe
[15:13] <jdstrand> wait, what was the link?
[15:13] <jdstrand> :P
[15:13] <rbasak> jdstrand: http://pad.ubuntu.com/mysql-arm64-corruption-patch :-P
[15:14] <mdeslaur> jdstrand: http://pad.ubuntu.com/mysql-arm64-corruption-patch
[15:14] <jdstrand> ah, right. thanks! :)
[15:14] <mdeslaur> hehe
[15:14] <mdeslaur> nerd humour
[15:14] <jdstrand> do we have an idea of when Oracle will fix it? eg, is there a reasonable expectation that it will be fixed for next quarter's update?
[15:15] <jdstrand> I agree with the agreement :)
[15:16] <jdstrand> please put it in the sru bug so they are aware too
[15:17] <mdeslaur> jdstrand: yes, that is the intention, as soon as dannf's manager signs off on it
[15:17] <jdstrand> great
[15:27] <teward> rbasak: incoming PM, unrelated
[16:06] <dannf> mdeslaur, rbasak, jdstrand : andrewc added some CYA text to the top, but otherwise approves. can we retroactively add this to the trusty release notes?
[16:07]  * rbasak scrolls back to find the link
[16:07] <rbasak> dannf: you might need to s/we/ with something to make it clear.
[16:08] <rbasak> I don't know whether retroactively changing the release notes is a thing
[16:08] <rbasak> There are point release release notes though
[16:08] <rbasak> Maybe a question for the release team.
[16:08] <dannf> ok
[16:09] <rbasak> I think it does make sense to alert users to the issue through the release notes in principle
[16:10] <dannf> so maybe just queue it up for the next point release if it hasn't been fixed properly by then
[16:10] <rbasak> I'll ask in #ubuntu-release
[16:37] <rbasak> jcastro: FYI https://lists.ubuntu.com/archives/technical-board/2015-July/002125.html thanks to teward
[16:39] <jcastro> git comm\o/
[16:39] <jcastro> whoops, I mean, yay! \o/
[16:39] <teward> lol
[16:39] <teward> jcastro: copy-paste fail? :P
[16:39] <jcastro> indeed
[16:40] <jcastro> more like window focus fail
[16:40] <jcastro> we really need a focus-follows-eyes window manager
[16:40] <teward> :P
[16:41] <teward> or direct neural communication with systems
[16:43] <teward> in any case this is up at the TB now, so we can only hope at this point :P
[16:45] <rbasak> Don't worry, the TB are on our side. They want Ubuntu to continue to be awesome too :-)
[16:46] <mdeslaur> dannf: cool, can I paste that into the SRU bug?
[16:47] <dannf> mdeslaur: yeah
[16:48] <mdeslaur> thanks dannf, rbasak!
[16:49] <dannf> rbasak: btw, is there an existing PPA/group that makes sense for these pre-release builds, or should i just shove one under ~ce-hyperscale?
[17:04] <rbasak> dannf: there's https://launchpad.net/~mysql-ubuntu
[17:04] <rbasak> dannf: however that isn't Canonical only, so I don't think we can get a devirt PPA there.
[17:05] <rbasak> I'm not sure of the current status of virt/scalingstack builders for arm64 and ppc64el. Might be worth enquiring.
[17:34] <Stuxnet> Hi all, newbie here, simple question. I access my server via ssh. When I first started I did the manual username/password and I would always get the default MOTD. Now I login by key authentication and no more MOTD. I even went into sshd_config and changed PrintMOTD to 'yes'. It prints last login but not MOTD. What gives?
[17:36] <Stuxnet> As a side note I've been doing key based login for a while now and I just happened to notice that I miss the motd.
[18:09] <pmatulis> Stuxnet: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/543767
[18:12] <Stuxnet> Oh okay well at least I know it's a bug. Why is it expired? Can it be reported again?
[18:13] <Stuxnet> I'm reading...
[18:14] <pmatulis> Stuxnet: just add a comment of your own. it doesn't seem right to me. i presume you are running 14.04?
[18:15] <pmatulis> Stuxnet: as a workaround you can always call motd from your init shell files. the bug mentions how
[18:17] <Stuxnet> Yes 14.04. I think I found the problem, about to test...
[18:18] <Stuxnet> Okay so
[18:18] <Stuxnet> I had to set UsePAM to yes in sshd_config and now it prints the motd
[18:19] <Stuxnet> Apparently the motd is generated with PAM
[18:20] <Stuxnet> These guys say that as long as challenge response authentication and password authentication are set to no and public key authentication is set to yes then it's fine
[18:21] <Stuxnet> Thanks guys!
[18:30] <pmatulis> Stuxnet: ok, i read it too quickly then
[18:36] <slowe> I'm using an internal mirror of Ubuntu 14.04 (amd64 architecture only), and I'm finding that I have to run "dpkg --remove-architecture i386" in order for things to work on 64-bit installs of Trusty. Is this expected? If so, is there a setting/way to automate this?
[18:36] <patdk-wk> yes
[18:36] <patdk-wk> there are 32bit packages required for some things
[18:37] <patdk-wk> so to mirror only the 64bit packages would cause an issue
[18:37] <slowe> patdk-wk: Can you elaborate on the required 32-bit packages?
[18:37] <patdk-wk> well, I have lots of 32bit that is required for my usage
[18:37] <patdk-wk> due to using 32bit compiled software on my 64bit system
[18:38] <slowe> patdk-wk: Let's assume that I'll only be using 64-bit software (these are stripped down server builds). Does that change the picture?
[18:39] <slowe> patdk-wk: Or is that assumption flawed? In other words, is it not possible to use only 64-bit software/packages on a typical Ubuntu Server build?
[18:40] <patdk-wk> you must have done something
[18:41] <patdk-wk> my desktop machine and some of my servers have a mixture of 64 and 32bit installed
[18:41] <patdk-wk> but my servers that I don't run outside binaries on, my pure basic ones true open source ones
[18:41] <patdk-wk> are purely 64bit
[18:41] <patdk-wk> dpkg --print-foreign-architectures
[18:41] <patdk-wk> that command says i386 on my desktop
[18:41] <patdk-wk> but normally nothing on my servers
[18:42] <patdk-wk> meaning only 64bit packages are installed
[18:42] <slowe> patdk-wk: When I run "dpkg --print-foreign-architectures" on the server(s), the result is empty (meaning only 64-bit packages are installed).
[18:42] <patdk-wk> dpkg -l will also show you what packages are i386
[18:43] <slowe> patdk-wk: However, when I try to use the amd64-only internal mirror, it will fail until I run "dpkg --remove-architecture i386". This is even though "dpkg --print-architecture" returns *only* "amd64".
[18:43] <patdk-wk> are you sure that is right?
[18:43] <patdk-wk> for me I get
[18:43] <patdk-wk> dpkg --remove-architecture i386
[18:43] <patdk-wk> dpkg: error: unknown option --remove-architecture
[18:44] <teward> patdk-wk: it's in the manpage
[18:44] <slowe> patdk-wk: This is 14.04.2
[18:44] <patdk-wk> I was on 12.04 by accident :)
[18:44] <slowe> patdk-wk: No worries :-)
[18:44] <teward> patdk-wk: https://pbin.dark-net.net/view/raw/3d72be32 <--- just for the future :)
[18:45] <patdk-wk> dpkg --remove-architecture i386
[18:45] <patdk-wk> dpkg: warning: cannot remove non-foreign architecture 'i386'
[18:45] <patdk-wk> that one is still running 14.04.0
[18:45] <slowe> patdk-wk: That's what I just got, but I'd already run it once, so I'm guessing the command isn't idempotent and tries to do something again.
[18:45] <patdk-wk> I should update it, it's just my source code repo, behind lots of firewalls :)
[18:46] <patdk-wk> well,I have never run that command before
[18:46] <patdk-wk> so by default atleast, i386 is not installed
[18:46] <slowe> patdk-wk: In any case, do you know of any file/setting that is modified by that command that I could track? This would allow me to use Ansible to run that command and then track if the command has been run before.
[18:46] <patdk-wk> you must have pulled something in, like say, java
[18:47] <patdk-wk> I don't know
[18:49] <slowe> patdk-wk: I'm using a plain jane Vagrant box I built myself using a standard Ubuntu Server 14.04 installation. I'll dig in a bit more---thanks for your help.
[18:50] <patdk-wk> updated to 14.04.2, still no i386
[18:51] <patdk-wk> 1190 packages installed
[18:51] <patdk-wk> mine are build using the normal, minimal-install virtual machine option, from the iso's
[18:59] <jrwren> slowe: you can answer this yourself by running strace and seeing which files dpkg --remove-architecture i386 removes.
[18:59] <jrwren> slowe: I used to rm -f /etc/dpkg/dpkg.cfg.d/multiarch to do the same thing.
[19:00] <slowe> jrwen: Thanks, I'll give strace a go. /etc/dpkg/dpkg.cfg.d/multiarch doesn't exist on these systems, though.
[19:02] <jrwren> slowe: did you already run dpkg --remove-arch... on those systems?
[19:03] <slowe> jrwen: Nope. This is on a fresh instance of a Ubuntu 14.04 Vagrant box, and "dpkg --print-foreign-architectures" does report "i386".
[19:04] <jrwren> slowe: Ok, thanks.
[19:04] <slowe> jrwen: However, I see a package called "multiarch-support"...going to try removing that to see if that does anything. (This is a Vagrant box, so no big deal if it blows up.)
[19:05] <slowe> jrwren: That won't work. Wants to remove most of the packages on the system. :-)
[19:08] <patdk-wk> how did you install?
[19:08] <patdk-wk> minimal install? or just normal?
[19:08] <patdk-wk> I can't think of anytime I have done a normal, non-minimal install
[19:09] <slowe> Found it...dpkg architectures are stored in /var/lib/dpkg/arch, each architecture on a separate line.
[19:11] <slowe> Removing "i386" from that line fixes the original issue AFAICT (internal amd64-only mirror works as expected with no errors). Now to automate this with Ansible...
[19:18] <jrwren> slowe[away]: works for me. I do it very often.
[19:22] <jrwren> slowe[away]: why the desire to remove foreign arch?
[19:38] <tgeek> Anyone here ever seen /dev/sda as "hp ilo internal sd-card".  I can't get kickstart to install lvm correctly because it always wants to install it there even when I tell it to install it to /dev/sdb which is my hdd.
[19:38] <bekks> Yes, almost every of our servers behaves like that.
[19:38] <tgeek> what's your workaround?
[19:39] <bekks> Either pull the sd card, or install to the /dev/cciss/ raid controller logical volumes you created before.
[19:40] <tgeek> that's nto exactly what I wanted to hear, but I appreciate the help.  Looks like a trip to the datacenter tomorrow.
[19:41] <bekks> I assume you have no raid controller then?
[19:42] <tgeek> I'm not really sure how to point it to /dev/cciss/.  Should I define that in the kickstart file?
[19:53] <tgeek> I'm doing a network install now without any automation.  In the beginning I did a rmmod usb_storage and when it came to the partition section, it didn't see it.  I'm going to try to incorporate that into the automated kickstart file.
[20:02] <slowe> jrwren: Sorry, had to step out for a bit. Need to remove foreign arch because internal amd64-only mirror won't work otherwise (apt-get reports can't find binary-i386 packages).
[20:03] <sarnold> slowe: did you try prefixing your apt entries with e.g. deb [arch=amd64] http://....  ?
[20:03] <slowe> sarnold: In sources.list?
[20:03] <sarnold> slowe: yeah
[20:04] <sarnold> https://wiki.debian.org/Multiarch/HOWTO
[20:05] <slowe> sarnold: No, hadn't tried that. Will give that a try! Is there a strong advantage one way or the other?
[20:06] <bekks> tgeek: First, make sure you have the required hardware :)
[20:06] <tgeek> I do
[20:07] <bekks> Then remember to create a logical volume on your raid controller before installing an OS.
[20:07] <bekks> Or automate it, using kickstart and an external script.
[20:07] <sarnold> slowe: heh, no, this was the easier way I found for dealing with a similar problem
[20:08] <slowe> sarnold: Fair enough :-)
[20:08] <sarnold> slowe: though perhaps it's nice i fyou've got multiple deb sources, and one of them is e.g. amd64 only, but your system still needs the 32 bit stuff from other mirrors
[20:08] <slowe> sarnold: Sure, that makes sense
[22:35] <Luke> anyone know how to start a systemd user service as a non-root user?
[22:44] <teward> anyone ever hear of a server randomly stop logging to syslog?
[22:44] <teward> or dmesg
[22:46] <ianorlin> teward: I have not
[23:01] <teward> ianorlin: nor have I, it's new to me to see that
[23:01] <teward> meh, not super important since all that's there is bind9
[23:08] <patdk-lap> you can't stop logging to dmesg, that is just not possible
[23:08] <patdk-lap> unlessthe kernel crashed
[23:08] <patdk-lap> now not logging to syslog is simple
[23:08] <patdk-lap> don't have syslog running, or have a read-only filesystem
[23:08] <patdk-lap> or bad permissions, or
[23:16] <sarnold> or a race condition between the log rotation and the logging system closing and opening the new file -- see if the logs are going to the .0 or .1 file instead
[23:20] <patdk-lap> yes, but still the *dmesg* command should always work
[23:20] <patdk-lap> dmesg log, totally different story
[23:22] <sarnold> yeah, dmesg should always work, but the benefit there is only the kernel gets to write to it :)
[23:22] <patdk-lap> yes
[23:46] <teward> patdk-lap: no dmesg either, which is REALLY odd
[23:46] <teward> and i rebooted the server just in case
[23:47] <teward> so maybe it's a perms problem
[23:47] <patdk-lap> the dmesg command?
[23:47] <teward> no output
[23:47] <teward> nor did /var/log/dmesg have anything
[23:47] <teward> which was really od
[23:47] <teward> odd*
[23:47] <patdk-lap> well /var/log/dmesg would be expected
[23:47] <patdk-lap> if syslog isn't working
[23:47] <teward> would the `dmesg` command still output?
[23:48] <patdk-lap> it should
[23:48] <teward> and if it doesn't
[23:48] <patdk-lap> unless something like /dev was messed up
[23:48] <teward> should i drop a nuke on the server?
[23:48] <patdk-lap> or apparmor gone nuts
[23:48] <teward> wouldn't put it past this VPS image
[23:48] <teward> but it was doing those before
[23:48] <patdk-lap> it's a vps?
[23:48] <teward> openvz but yes
[23:48] <patdk-lap> oh probably shouldn't work then
[23:48] <teward> heh
[23:48] <teward> i know syslog was working though
[23:49] <teward> because bind9 would report there
[23:49] <patdk-lap> ya, that is different and *probably* easy to fix
[23:49] <patdk-lap> openvz I haven't used for a long time
[23:49] <patdk-lap> but it likely doesn't allow dmesg usage, cause you don't own the kernel
[23:49] <patdk-lap> the provider does
[23:49] <teward> mhm
[23:49] <teward> i'm not horribly worried about it, i could tell bind9 to log to a file instead of syslog but i'm lazy
[23:50] <patdk-lap> I could be wrong, never used openvz much, but it does block lots of kernel things
[23:50] <sarnold> openvz may force kernel.dmesg_restrict=1 in their containers..
[23:53] <teward> sarnold: quite possible.  i'm looking to put bind9 to a file rather than syslog where i can, now, since that's really the only log I care about


[16:01] <genii> Riku-san_: For your issue with Ubuntu on the Nexus 7, #ubuntu-touch channel may yield better results
[21:45] <Riku-san_> genii: already been there, I never fixed it since "unsupported, use ubuntu touch, oh your device is unsupported"
[21:45] <Riku-san_> I got Ubuntu Touch installed, but it's hanging


[04:10] <PerfM> LOL
[04:10] <PerfM> woooop woooop
[06:14] <pangolin> @mark #ubuntu iToast<EMAIL_ADDRESS>spoke to in PM and explained that the off topic must stop.
[06:19] <pangolin> atvr: How can I help you?
[06:20] <atvr> pangolin, nothing, i was just looking what was the channel
[06:21] <pangolin> this channel is used for ban resolution mostly
[06:21] <atvr> pangolin, okay thanks
[06:21] <pangolin> We ask that users not idle so we can keep track of who needs help.
[06:21] <pangolin> sure thing.
[06:21] <atvr> i will leave :)
[08:00] <elky> why do i sense that the TMI is going to be strong in this one?
[11:28] <jussi> Im in PM with Mr_Queue about the command he just posted
[11:35] <jussi> !away > guampa
[11:37] <bazhang> jussi, just by searching channel: #ubuntu , the bantracker returns to the default behaviour (previously listing most recent actions)
[18:54] <Resistance> bouncybounce has a URL resolver in #ubuntu
[18:55] <Resistance> isnt that against channel rules?
[18:55] <Resistance> since it resolved links from ubottu, then caused ubottu to respond twice (taking up channel space)
[18:56] <pangolin> thanks Resistance
[18:57] <Resistance> yep
[23:32] <Jordan_U> In #ubuntu "15:31 -!- Jasonn is now known as PerfieM    15:31 -!- PerfieM is now known as Jasonn"
[23:43] <jtrucks> they are actually separate people. looks like jasonn was acting up...


[13:02] <G64> Hi everyone :)
[13:02] <G64> Great to see there is a dedicated Mythbuntu channel :)
[13:04] <G64> Last night i have set up a Mythbuntu system
[13:04] <G64> And i hope (when needed) that you are willing to help me out with some questions i might have :)
[13:06] <G64> Oh, hi SteveGoodey :) , You are here too :)


[02:59] <ctcb> Hi all...
[03:10] <pitti> Good morning
[03:15] <mfisch> hey mhall119 you around?
[03:15] <mhall119> kinda
[03:15] <mhall119> what's up?
[03:16] <mfisch> mhall119: I was looking at the popcon merge, is the server still non-functional?
[03:19] <mhall119> mfisch: if you look at the table at the bottom of http://popcon.ubuntu.com/
[03:19] <mhall119> there are non-architectures in the architectures statistics
[03:19] <mfisch> like dpkg
[03:19] <mfisch> and "Here" ;)
[03:19] <mhall119> yeah
[03:20] <mhall119> I have 1.21 GHz Here processor :)
[03:20] <mfisch> okay, but it's not 100% non-functional, just a bit screwed up
[03:20] <mhall119> I think so, I'm not to familiar with what is supposed to be there
[03:20] <mfisch> ok
[03:20] <mfisch> I'll test out the new version
[03:20] <mhall119> but pabs from debian pings me about it, because evidently they use the data for something
[03:20] <mfisch> I think it reports 1 extra field and so I'll see what happens when I use it
[03:22] <mhall119> thanks
[03:23] <mhall119> hey mfisch, I may need to write an online-accounts provider in the next couple weeks, can I ping you if I need help?
[03:24] <mfisch> sure, but I Think cwayne did that not me
[03:24] <mfisch> for fitbit
[03:24] <mhall119> I thought you guys did it together
[03:24] <mfisch> he did the accounts thingy and I wrote the piece that used it
[03:24] <mhall119> ah, ok
[03:24] <mfisch> but its part of our team charter to support stuff like that so please ping us
[03:24]  * mhall119 goes to work for lead developer cwayne
[03:25] <mfisch> oh hey mhall119 when is the dash going to work on the phone?
[03:25] <mhall119> it does, kinda
[03:25] <mhall119> search on the Home lens is disabled intentionally, I was told, because it'd be too slow right now if you tried to use it on a device
[03:26] <mhall119> Saviq can tell you more though
[03:27] <mfisch> thanks
[03:28] <mfisch> mhall119: how can I tell that pop-con uploaded successfully?
[03:28] <mfisch> do you have logs there or would there be an obvious failure
[03:28] <mhall119> I have no idea, sorry
[03:33] <mhall119> mfisch: man, I make a personal introduction and he sends you to a mailing list, that's cold
[03:33] <mfisch> yeah, oh well ;)
[03:33] <mfisch> thanks
[03:34] <mfisch> This feature was "Suggested by Paul Wise."
[03:34] <mfisch> I just want to make sure it doesn't break your server
[03:35] <mhall119> my server?
[03:35] <mfisch> I mean popcon.ubuntu.com
[03:35] <mhall119> ah, ok
[03:36] <mhall119> really, I only cared about it because folks in debian did
[03:36] <mhall119> and I was working to help them
[03:36] <mfisch> well I told seb that I didn't want to merge this until I knew it was safe
[03:36] <mfisch> but it's becoming more trouble that it's probably worth
[03:37] <mhall119> :/
[05:06] <didrocks> good morning
[05:43] <Mirv> didrocks: I added a new item to our task list, a largish precise SRU needed
[05:44] <didrocks> Mirv: excellent, do you have time to handle it or need someone else to do it?
[05:45] <Mirv> didrocks: I'm trying to handle it to an extend today/tomorrow, but whatever is left undone will need to be handled by eg. sil2100 then
[05:45] <Mirv> didrocks: I'm again in a situation that I've tons of stuff to do, and I'm unsure of the ordering :)
[05:45] <Mirv> didrocks: in good news, I solved armhf build failures with switchin to g++-4.7 for armhf temporarily
[05:46] <Mirv> didrocks: so qtwebkit is ready to upload (soon, with mitya57's changes merged)
[05:46] <Mirv> didrocks: and I should ping you about Qt Creator as well (hey I just did that), it should be ready for your eyes as well
[05:46] <Mirv> since it also failed on armhf, but succeeded now during the night with g++-4.7
[05:46] <didrocks> Mirv: ah, great! please copy the link in the spreadsheet :)
[05:47] <didrocks> Mirv: can you quiclky do (it should take few minutes) the publication of the day for your stacks?
[05:47] <didrocks> so that it's in latest phone imag?
[05:47] <didrocks> image*
[05:47] <Mirv> didrocks: ah yes that, doing that now, then trying to put all the needed links and branches in and then I'll ping you again, and then continue with the precise SRU
[05:49] <didrocks> Mirv: perfect, thanks!
[05:49]  * didrocks cleans the spreadsheet at the same time
[05:51] <Mirv> didrocks: as platform is in manual publishing mode, I'd need an ack from you for that. the packaging changes seem fine for me. location-service change was done by you so I guess that's an 'ack', and then there's powerd.
[05:52] <didrocks> Mirv: indeed, I did that change, so I can only +1 I think :p powerd is looking good (less hacks \o/)
[05:54] <didrocks> Mirv: can you send an email then to the SRU team for the xim support in precise? I think they would prefer to open the discussion before the raring upload
[05:54] <didrocks> precise*
[05:58] <Mirv> stacks published
[05:58] <Mirv> didrocks: ok
[05:59] <didrocks> Mirv: thanks!
[05:59]  * didrocks is handling the raring SRU quickly
[06:25] <veebers> didrocks: ping
[06:25] <didrocks> veebers: pong
[06:26] <veebers> didrocks: how's things going? o/ Hey I'm interesting in using otto in a similar jenkins jobs setup to what the Unity autopilot or Autopilot daily jobs are doing to replace an old non-working job of mine
[06:26] <veebers> didrocks: I'm hoping you can point me in the right direction
[06:26] <veebers> didrocks: specifically the job should grab an unity branch, build the packages and install them then run the unity autopilot tests over them (where the branch that is built and installed is a parameter)
[06:27] <veebers> didrocks: although, initially the branch doesn't have to be a param, I can hardcode it as I'm more interested in the one off right now
[06:28] <didrocks> veebers: what are you trying to do with this? I'm wondering why we would need to yet build another time the same sources we have instead of using validated version?
[06:29] <veebers> didrocks: the reason is I had this job [1] that built a 'custom' version of unity so that a developer could test their changes. (http://<IP_ADDRESS>:8080/job/autopilot-run-custom-branch-saucy)
[06:29] <veebers> but It's been unmaintained and so doesn't work at the moment
[06:29] <didrocks> veebers: shouldn't that rather be a feature branch?
[06:30] <didrocks> veebers: and so having daily release to a ppa and so on
[06:30] <didrocks> I'm afraid that we have: 1. too many ppas and people are lost in versions
[06:30] <didrocks> 2. too many methods to build sources and packages
[06:30] <didrocks> (mir itself has 3 different ways to build itself used by upstream, 2 of them being hackish script and demanding updating the build-deps in various places)
[06:30] <veebers> didrocks: this one instance is a developer want's to test his changes before proposing a MP
[06:31] <didrocks> veebers: I would say then, for building, it would be better to use something similar than the upstream merger
[06:31] <didrocks> then, grab the deb, create a local repo
[06:31] <didrocks> and using that with an otto job that is similar to ours
[06:32] <didrocks> Mirv: I think you didn't update the version on debian/changelog compared to the tarball, right? Trying that
[06:32] <veebers> didrocks: sure alright makes sense. Can you link me to where I can see/learn about the otto job so that I can steal err borrow it's config?
[06:33] <didrocks> Mirv: hum, the patches are then rejected, are you sure you pushed your qtpim branch to latest?
[06:33] <didrocks> veebers: oh, sure, look at http://<IP_ADDRESS>:8080/job/autopilot-saucy-daily_release/
[06:33] <didrocks> veebers: and tell me if anything doesn't make sense :)
[06:33] <didrocks> the runs are tagged with stacks it's built
[06:34] <didrocks> veebers: and you can see, almost no red in the runs! :-)
[06:34] <veebers> didrocks: awesome cheers, I've just been called to tea but will be back to probably ask more questions :-)
[06:34] <veebers> ^_^
[06:34] <didrocks> veebers: and the red are missing package in list, so wanted failures ;)
[06:34] <didrocks> veebers: enjoy your tea!
[06:42] <Mirv> didrocks: just a moment
[06:42] <Mirv> didrocks: hey, some push is very much missing, yes
[06:43] <didrocks> Mirv: thx
[06:43] <Mirv> didrocks: ok, qtpim pushed again
[06:43] <didrocks> will review :)
[06:43] <Mirv> didrocks: the licenses went upstream so that patch was removed then
[06:43] <didrocks> excellent :)
[06:46] <Mirv> didrocks: Qt Creator links in the spreadsheet now
[06:47] <Mirv> that's a big one
[06:47] <Mirv> I'll have the qtwebkit saucy update later today
[06:48] <didrocks> sponsoring day for me I guess :)
[06:56] <didrocks> Mirv: qtpim sponsored
[06:57] <Mirv> nice, I'll let Bill and Renato know
[06:57] <didrocks> great!
[06:57] <didrocks> qtcreator now
[06:59] <didrocks> Mirv: the plugins for qtcreator are still as distro patch in the branch, right?
[07:00] <veebers> didrocks: uh, first silly question; What does `$HOME/bin/run_otto_job` expand to so I can see the script?
[07:02] <didrocks> veebers: it's just in the otto source (see the jenkins/ directory)
[07:02] <veebers> didrocks: ah ok, cheers
[07:02] <didrocks> yw ;)
[07:05] <Mirv> didrocks: yes, still like that, the qtcreator-dev is not here yet
[07:05] <didrocks> ok
[07:06] <rickspencer3> woah, lots of new desktop stuff today
[07:07] <didrocks> hey rickspencer3!
[07:07] <rickspencer3> ey didrocks
[07:07] <rickspencer3> no, I'm not hear to harp on daily quality ;)
[07:08] <didrocks> Mirv: heh :)
[07:09] <didrocks> rickspencer3: you don't need to ;)
[07:09] <jibel> good morning
[07:09] <didrocks> Mirv: hum, you added a build-dep on libqt5-help5
[07:09] <rickspencer3> hi jibel
[07:09] <didrocks> Mirv: in the end, we have twice this build-deps now, can you remove one please?
[07:09] <didrocks> hey jibel!
[07:09] <jibel> Hi rickspencer3
[07:09] <jibel> bonjour didrocks
[07:11] <Mirv> didrocks: removed and pushed
[07:11] <didrocks> Mirv: thanks!
[07:28] <didrocks> Mirv: hum, I'm seeing on one patch:
[07:28] <didrocks> --desktop_file_hint=/home/phablet/…
[07:28] <didrocks> rev 75
[07:28] <didrocks> that doesn't seem scalable and adapting to other env, do you have some background on that?
[07:28] <Mirv> didrocks: it's on the device, I'd think. ie commands run there
[07:28] <Mirv> and there the home dir is that always
[07:29] <didrocks> Mirv: yeah, that's a pity it's harcoded, I think one day, we have the potential to change the name
[07:29] <Mirv> yep, it even runs the app on device for you
[07:29] <didrocks> Mirv: mind putting something on the top description of the patch?
[07:29] <didrocks> so that if one day we change the user
[07:29] <didrocks> we can find that more easily :)
[07:31] <Mirv> didrocks: added and pushed
[07:34] <didrocks> trying building
[07:37] <seb128> hey desktopers
[07:37] <didrocks> salut seb128!
[07:38] <seb128> didrocks, lut ;-)
[07:42] <tjaalton> is it known that U1 is broken on saucy?
[07:42] <tjaalton> client crashes with "ipcerror"
[07:43] <tjaalton> found it
[07:45] <seb128> tjaalton, that one is not known to me, it asserting due to the new python-configglue is known though
[07:45] <seb128> slangasek just uploaded a revert for that
[07:45] <tjaalton> oh
[07:45] <tjaalton> yeah that's the bug I found
[07:45] <tjaalton> I'll check out the upload queue, thanks
[07:47] <tjaalton> yep, fixed it for me too
[07:47] <tjaalton> syncing again, *phew*
[07:48] <pitti> bonjour seb128 !
[08:03] <Laney> hey
[08:06] <seb128> Laney, good morning, how are you?
[08:07] <Laney> seb128: not bad thanks, got a working indicator-applet again!
[08:07] <Laney> you?
[08:08] <seb128> Laney, I'm good thank
[08:08] <seb128> s
[08:08] <seb128> Laney, you should use unity!
[08:08] <Laney> I do on my main machine :P
[08:10] <Laney> not sure what would happen to my brain if my sexy xmonad configuration went away on the laptop
[08:11] <didrocks> hey Laney!
[08:11] <Laney> greetings didrocks!
[08:35] <seb128> sil2100, hey, how are you?
[08:36] <seb128> sil2100, I noticed that the indicator stack is not published yet, is there anything blocking it?
[08:39] <sil2100> seb128: looking, will need an packaging ACK
[08:39] <sil2100> http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/Indicators/job/cu2d-indicators-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_libusermetrics_1.0.6+13.10.20130711-0ubuntu1.diff
[08:39] <sil2100> seb128: just to be sure... google-mock 1.6.0+svn437 is available in distro?
[08:41] <seb128> sil2100, euh, I can think about half a dozen way for you to get that information
[08:41] <seb128> sil2100, launchpad, apt, rmadison
[08:41] <seb128> sil2100,
[08:41] <seb128> $ rmadison -S google-mock -s saucy
[08:41] <seb128> google-mock | 1.6.0+svn437-0ubuntu1 |         saucy | source, amd64, armhf, i386, powerpc
[08:41] <sil2100> seb128: I was asking because apt says differently
[08:41] <seb128> use rmadison
[08:41] <seb128> that's checking at the source
[08:41] <sil2100> apt-cache policy google-mock
[08:41] <sil2100>  *** 1.6.0-0ubuntu3 0
[08:41] <sil2100> Ok
[08:42] <seb128> did you run apt-get update?
[08:42] <sil2100> Yes, just a moment ago
[08:42] <seb128> do you use the main archive or a mirror?
[08:42] <sil2100> http://pl.archive.ubuntu.com/ubuntu/ <- maybe that's why?
[08:42] <seb128> yep
[08:42] <seb128> mirrors are often outdated
[08:42] <sil2100> Stupid polish mirror
[08:42] <seb128> in any case use rmadison when you need to know that
[08:43] <sil2100> Right, now I know it's more reliable ;) Anyway, I think it's ok for publishing, yes?
[08:43] <seb128> sil2100, also is there anything we can do have those easy diffs reviewed a bit earlier in the day so the update is available early for those who wait on it?
[08:43] <seb128> sil2100, seems ok to me yes ;-)
[08:44] <sil2100> seb128: I'll try to do that much earlier ;p I usually tend to wake up and start with what I didn't finish the last day
[08:44] <sil2100> While I probably should do the stacks first
[08:44]  * didrocks really thinks that publication should be the first thing we do in the morning :)
[08:44] <didrocks> Mirv: sil2100 ^
[08:44] <didrocks> (IIRC, I've repeated that a lot :p)
[08:45] <sil2100> didrocks: sorry guys ;p I know I know, it's just when you're irritated about something not working from yesterday, you want to fix it as soon as possible ;p
[08:46] <didrocks> Mirv: qtcreator sponsored
[08:47] <sil2100> didrocks: just so you know - the Apps stack is blocked until Florian fixes the toolkit regression
[08:47] <sil2100> https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1199662
[08:47] <ubot2`> Ubuntu bug 1199662 in Ubuntu UI Toolkit "New easing causes animations not to reach their target values" [Critical,Confirmed]
[08:48] <didrocks> sil2100: can we work with them to run some apps autopilot tests with their stack?
[08:48] <didrocks> sil2100: to ensure they don't regress
[08:49] <sil2100> I guess, but changes like these should actually be tested by the UI toolkit, maybe unit-tested or something
[08:49] <didrocks> sil2100: ah, not sure for that one in particular, but in general?
[08:49] <sil2100> Since sometimes, well, the UI toolkit changes something and breaks the Apps on purpose
[08:49] <didrocks> sil2100: not the first time the toolkit is breaking apps
[08:49] <sil2100> This would maybe create a bit of a deadlock then
[08:50] <didrocks> well, they need to ensure that apps are adapted first
[08:50] <didrocks> if they don't want backward compatibility
[08:50] <sil2100> didrocks: I'll have a talk with kaleo and others today about that then, might be a good idea to have something more
[08:51] <didrocks> sil2100: thanks!
[08:51] <didrocks> sil2100: I'll add the missing autopilot tests today
[08:51] <didrocks> sil2100: the remaining things to look for is unity, right?
[08:51] <didrocks> sil2100: I've published the raring oif SRU (the libgrip fix) which was waiting for a week FYI
[08:52] <sil2100> didrocks: awesome, right - I forgot that now 'publishing' the raring stack means pushing to the SRU PPA ;/
[08:52] <sil2100> didrocks: thanks!
[08:53] <sil2100> didrocks: I already poked Wellark and waiting for him to pop up, also we need Ted to resolve unity issues
[08:53] <didrocks> sil2100: yw ;)
[08:53] <didrocks> ok, good!
[08:54] <Laney> mlankhorst: can you help find the right way to fix omap4 images please? :(
[08:55] <Laney> I don't know where to add the reverted xorg
[08:56] <mlankhorst> Laney: erm what is the build recipe it is using atm?
[08:57] <Laney> well part of my problem is that I'm not entirely sure which seeds it's using
[08:57] <seb128> ogra_ probably knows
[08:58] <ogra_> mlankhorst, whats the reason you didnt just add it as dependency to pvr ?
[08:58] <Laney> it depends on the abi but nothing which provides that is pulled in
[08:58] <mlankhorst> lack of upload rights, I guess :)
[08:58] <seb128> Mirv, did you see my debug comment ont he qtsystems bug? can you fwd to the upstream tracker? (I don't have a login there)
[08:59] <mlankhorst> but I'll make the change and then ask someone to sponsor it
[08:59] <seb128> Laney, we should just do what ogra suggests, add a direct depends on the server to pvr
[08:59] <ogra_> Laney, pvr just needs a dep added, you dont want to sered that package (that would break all other arm desktop installs since it uses the normal ubuntu-desktop seed
[08:59] <ogra_> )
[09:00] <ogra_> s/sered/seed/
[09:00] <Laney> yeah?
[09:01] <xclaesse> wow, .cache/friends/avatars contains 12k files for almost 500Mb
[09:03] <Laney> mlankhorst: ogra_: like this: http://paste.ubuntu.com/5864264/ ?
[09:03] <Laney> I'm curious as to where pvr-omap4 gets pulled in though
[09:04] <ogra_> Laney, perfect
[09:04] <Laney> ah via supported-hardware-desktop
[09:06] <mlankhorst> yeah something like that :)
[09:06] <Mirv> didrocks: awesome! (qtcreator)
[09:06] <mlankhorst> actually the xserver-xorg-dev dependency could be dropped entirely afaict
[09:07] <didrocks> Mirv: nice work!
[09:07] <Mirv> seb128: I saw, I can mention it at the upstream tracker as well
[09:07] <Laney> I'll leave it
[09:07] <Laney> don't fancy doing another test build
[09:10] <seb128> Mirv, thanks
[09:11] <Mirv> (mentioned)
[10:00] <didrocks> sil2100: ah great! so all the things I listed on column E9 are DONE (apart qtvideo-node)?
[10:02] <didrocks> sil2100: btw: https://code.launchpad.net/~didrocks/cupstream2distro-config/share-app/+merge/174149
[10:04] <didrocks> sil2100: FYI, the thing that will never daily release, they need to be moved to "online" release (that we should "$ bzr mv online merge-only" I think)
[10:29] <Laney> yay, sorting works
[10:32] <seb128> Laney, \o/
[10:52] <sil2100> ACK
[10:52] <sil2100> didrocks: yes
[11:14] <Mirv> 11 apport collection processes at the same time slows down machine a bit..
[11:42] <didrocks> sil2100: I'm relaunching tha app stack for the tests only
[11:53] <sil2100> didrocks: ok, was the toolkit issue fixed or just to check shared-app?
[11:54] <didrocks> sil2100: just to check share-app
[11:54] <didrocks> for the toolkit and the new packages, I'll let you deal with those, right?
[11:54] <sil2100> Yessss
[12:25] <mlankhorst> Laney: oh btw did adding that to powervr help?
[12:25] <mlankhorst> hm guess you didn't try
[12:25] <Laney> mlankhorst: we'll find out when the next image build happens tomorrow morning
[12:26] <mlankhorst> oh sure
[12:34] <Mirv> didrocks: https://code.launchpad.net/~timo-jyrinki/ubuntu/saucy/qtwebkit-opensource-src/arm-fix-and-docs-packages/+merge/174184
[12:34] <Mirv> that would be the webkit thing from mitya57, my arm fix and your ubuntu3 patch
[12:35] <Mirv> didrocks: if you want, I could do one more PPA build for tomorrow. a 5.0.2 build finished successfully also for arm, but since the DPR is broken on 5.0.2 I asked mitya57 to do the docs thing for 5.0.1 and now the delta is smaller.. it does compile on amd64 and the g++-4.7 should take care of the ARM like it did now so far with Qt 5.1.0 and 5.0.2
[12:38] <didrocks> Mirv: yeah, that would appreciated :)
[12:38] <didrocks> there is no urgency for today, right?
[12:39] <Mirv> didrocks: ok. yeah no urgency.
[12:39] <didrocks> ok :)
[13:49] <kenvandine> sil2100, thanks for fixing the build failures in qtvideo-node
[13:50] <sil2100> kenvandine: no problem :)
[13:50] <kenvandine> sil2100, i merged the rest of my changes in my old failing branch into a new one that depends on your's
[13:50] <sil2100> kenvandine: hmmm! Since you're around!
[13:50] <kenvandine> can you review?
[13:50] <kenvandine> https://code.launchpad.net/~ken-vandine/qtvideo-node/run_tests/+merge/174204
[13:50] <sil2100> kenvandine: sure ;)
[13:50] <sil2100> kenvandine: could you tell me what's up with webaccounts-browser-extension ?
[13:50] <kenvandine> the most important part is adding the check target, so it actually runs the tests :)
[13:50] <kenvandine> sil2100, yeah... we didn't want to autoland it without any integration tests
[13:51] <sil2100> kenvandine: any luck with that?
[13:51] <kenvandine> not yet... i still need to figure out how to run otto and fix up those autopilot tests :)
[13:51] <kenvandine> didrocks, got time to walk me through setting up otto?
[13:52] <didrocks> kenvandine: we are going to write what it takes to set it up tomorrow on the phone, so maybe it will be a better time, wdyt?
[13:52] <sil2100> kenvandine: hmm, but I saw the unit-test being run during build I think
[13:52] <didrocks> kenvandine: as I think you want first to install/run it on the phone?
[13:52] <kenvandine> nope
[13:52] <kenvandine> :)
[13:53] <kenvandine> it builds unittests
[13:53] <kenvandine> doesn't run them
[13:53] <sil2100> make[3]: Wejście do katalogu `/opt/tmp/canonical/stacks/review/build-area/qtvideo-node-0.2.1daily13.06.07/unittests/shadervideonode'
[13:53] <sil2100> LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}  ./tst_shadervideonode
[13:53] <sil2100> ********* Start testing of tst_ShaderVideoNode *********
[13:53] <sil2100> Config: Using QTest library 5.0.2, Qt 5.0.2
[13:53] <sil2100> PASS   : tst_ShaderVideoNode::initTestCase()
[13:53] <kenvandine> i didn't get that!
[13:53] <sil2100> QWARN  : tst_ShaderVideoNode::testCameraSetCurrentFrame() No camera control or media player control instance included in video frame
[13:53] <sil2100> PASS   : tst_ShaderVideoNode::testCameraSetCurrentFrame()
[13:53] <kenvandine> without adding the check target
[13:53] <sil2100> QWARN  : tst_ShaderVideoNode::testMediaPlayerSetCurrentFrame() No camera control or media player control instance included in video frame
[13:53] <kenvandine> weird
[13:53] <sil2100> PASS   : tst_ShaderVideoNode::testMediaPlayerSetCurrentFrame()
[13:53] <sil2100> PASS   : tst_ShaderVideoNode::cleanupTestCase()
[13:53] <sil2100> Totals: 4 passed, 0 failed, 0 skipped
[13:53] <sil2100> Since that's what the testcase CONFIG does I guess
[13:53] <sil2100> ********* Finished testing of tst_ShaderVideoNode *********
[13:53] <sil2100> Here it runs?
[13:53] <sil2100> This is output from bzr bd
[13:53] <kenvandine> that is what i did too...
[13:54] <kenvandine> weird
[13:54] <sil2100> kenvandine: btw2. is it safe to change existing changelog contents? ;)
[13:55] <sil2100> kenvandine: since I have overriden the lintian warning, because I thought that existing changelog entries should stay intact, since those are released already
[13:55] <sil2100> didrocks: ^ what's the rule with that?
[13:55] <kenvandine> sil2100, i'd rather fix it
[13:55] <kenvandine> it's safe
[13:56] <didrocks> sil2100: yeah, I agree with kenvandine
[13:56] <didrocks> if it's for fixing a lintian warning, better to fix the changelog
[13:56] <didrocks> (even if already released)
[13:56] <kenvandine> especially since we know his email address :)
[13:56] <didrocks> they even rewrote the history in latest doctor who (spoiler), so we can do as well :)
[13:56] <kenvandine> haha
[13:56] <kenvandine> didrocks, no spoilers!
[13:57] <kenvandine> i'm a whole season behind
[13:57] <kenvandine> :-D
[13:57] <didrocks> kenvandine: I won't go further! :p
[13:57] <didrocks> kenvandine: just though to tell you that…
[13:57]  * didrocks runs away
[13:57] <didrocks> :)
[13:57] <kenvandine> :)
[13:57] <kenvandine> tomorrow is fine
[13:57] <didrocks> whole season in a day?
[13:57] <kenvandine> i'm feeling a bit behind anyway, i'd rather work on something else that i haven't even started
[13:57] <didrocks> or you are speaking about otto? :p
[13:57] <kenvandine> didrocks, haha
[13:57] <kenvandine> otto
[13:57] <kenvandine> :-D
[13:57] <didrocks> ;)
[13:58] <kenvandine> larsu, speaking of tasks i really need to get started on... want to step through the new indicators-client stuff?
[13:58] <kenvandine> for messaging menu?
[13:58] <sil2100> kenvandine: could you remove the lintian-overrides then ;)?
[13:58] <kenvandine> sil2100, sure
[13:59] <kenvandine> sil2100, ok... your branch does run the tests for me in pbuilder
[13:59] <kenvandine> but it didn't in bzr bd
[13:59] <kenvandine> weird
[13:59] <kenvandine> i'll remove that change in my branch
[13:59] <larsu> kenvandine: well, I haven't started on messaging menu yet, because somebody noticed we have indicators in the greeter :)
[13:59] <larsu> kenvandine: but sure, what do you want to do?
[14:00] <kenvandine> i need to turn back on adding facebook stuff in messaging menu
[14:00] <kenvandine> and do the inline replies
[14:00] <kenvandine> like we do for SMS
[14:00] <kenvandine> remember you said i would be surprised how easy it is?
[14:00] <larsu> I do!
[14:00] <larsu> and you will be!
[14:01] <larsu> are you going to be using this from c++?
[14:01] <kenvandine> well... adding the entry should be from vala
[14:02] <kenvandine> not sure what the code will be like for replying
[14:02] <kenvandine> i think that is what you said would be easy :)
[14:02] <larsu> ya that's fine as well, libmessaging-menu has gir
[14:03] <larsu> so the biggest problem is that you need the branch of libmessaging-menu that we're using on the phone
[14:03] <larsu> I have no idea where that is packaged, the upstream is lp:indicator-messages/phablet
[14:04] <larsu> like I said, I'll be working on consolidating these branches very soon
[14:04] <larsu> but I haven't gottent around to it yet
[14:06] <kenvandine> sil2100, i updated that branch
[14:06] <kenvandine> larsu, that is fine, i can do the development on the phone
[14:07] <sil2100> kenvandine: will review in a moment :)
[14:08] <larsu> kenvandine: awesome. I'm trying to find an example, but I can't ...
[14:08] <kenvandine> great :-D
[14:08] <kenvandine> larsu, you should include examples in the source :)
[14:08] <kenvandine> like tedg always did
[14:08] <kenvandine> :-D
[14:09] <larsu> kenvandine: well, there are, but not for the new stuff that I hacked for the demo
[14:09] <larsu> kenvandine: I'll write one, but the gist is this:
[14:09]  * tedg wipes a tear and thinks: "kenvandine misses me"
[14:09] <larsu> in addition to sources, you can now also add MessagingMenu.MessageS to an MessagingMenuApp
[14:09] <kenvandine> tedg, every once in a while i do :)
[14:09] <larsu> http://bazaar.launchpad.net/~indicator-applet-developers/indicator-messages/phablet/view/head:/libmessaging-menu/messaging-menu-message.h
[14:10] <larsu> that represents one of those "hero items"
[14:10] <larsu> and it can take an arbitrary amount of actions with parameters
[14:11] <larsu> if there's one action with one string parameter, it will be rendered as a text entry field
[14:12] <larsu> kenvandine: messaging_menu_message_add_action (msg, "id", "Reply", G_VARIANT_TYPE_STRING, NULL)
[14:12] <larsu> and then connect to the "activate" signal of that message, which gives you the parameter in a variant
[14:12]  * larsu cooks up an example real quick
[14:13] <kenvandine> i think i understand
[14:29] <Laney> phwoar, super hot & nice outside
[14:33] <desrt> Laney: did the g-c-c stuff get settled?
[14:34] <Laney> desrt: settled how?
[14:34] <desrt> landed, no more infinite loops and no regressions?
[14:34] <Laney> well it's in saucy
[14:35] <desrt> so yes, i guess, otherwise i would have heard about it? :)
[14:35] <Laney> Can't see any new bug reports
[14:35] <Laney> and nobody has complained to me
[14:35] <desrt> cool!
[14:35] <Laney> so ... seems ok so far
[14:35] <desrt> thanks
[14:35] <Laney> that u-p-s job race is annoying though
[14:37] <larsu> kenvandine: something like this should work: http://paste.debian.net/15543/
[14:38] <kenvandine> larsu, thanks!
[14:39] <larsu> kenvandine: there are also docsrings in the source, so making the docs yourself might help a bit too. Sorry about the state of all this right now
[14:39] <larsu> kenvandine: at least I'm working on gsettings-qt model support today :)
[14:41] <kenvandine> larsu, that's awesome too :)
[14:48] <kgunn_> mlankhorst: ping
[14:48] <mlankhorst> pong
[14:57] <jbicha> mpt: setting "Log on without a password" breaks sudo and any admin authentication prompts
[14:57] <jbicha> you can try it for yourself by going into User Accounts Settings, click Unlock, click Password
[14:58] <jbicha> for Action, set Log in without a password
[14:58] <jbicha> then try re-locking User Accounts and unlocking
[14:58] <jbicha> it won't work until you first click Password again and set a password
[14:59] <mdeslaur> jbicha: why is it breaking everything? it should just add you to a group
[15:00] <jbicha> it actually blanks your password, not adds you to a group
[15:00] <mdeslaur> well, that's broken
[15:01] <jbicha> oh I see that I'm in the nopasswdlogin group
[15:01] <mdeslaur> it should simply add you to the nopasswdlogin group
[15:01] <mdeslaur> but not disable your password
[15:01] <mdeslaur> hrm, accountsservice is doing both for some reason
[15:02] <jbicha> then I guess it's an accountsservice bug, I'm using http://www.valadoc.org/#!api=accountsservice/Act.User.set_password_mode
[15:03] <mdeslaur> hrm, using the nopasswdlogin group is a ubuntu-specific patch apparently
[15:03] <mdeslaur> well, ubuntu/debian specific
[15:03] <mdeslaur> what a mess
[15:07] <mdeslaur> hrm, ok, so both removing the password, and adding to the group should be ok
[15:07] <jbicha> oh? let me log out
[15:08] <mdeslaur> not sure why polkit isn't handling it...pam module config seems ok
[15:08] <didrocks> kenvandine: sil2100: Mirv: FYI, we fixed otto dependency detection, so expect some dependency adjustement tomorrow
[15:09] <didrocks> sil2100: then, for looking at what packages are not needed for listing anymore, just look at the "new packages to install" and you will have the list I guess ;)
[15:09] <jbicha> mdeslaur: yeah logging out didn't help (I'm using gdm)
[15:10] <sil2100> didrocks: well, my cleanup branch is waiting for approval all the time ;p
[15:10] <didrocks> sil2100: did you made the list from the logs?
[15:11] <sil2100> didrocks: manually actually!
[15:11] <mdeslaur> jbicha: hrm, does in fact seem broken with sudo and policykit
[15:12] <jbicha> it would be cool if that patch were upstream because once that bug is fixed, I believe the User Accounts panel still won't be designed to handle "log in without a password" correctly
[15:13] <mdeslaur> jbicha: we could just rename all these options "Break my computer" and be done with it
[15:14] <mdeslaur> :)
[15:15] <jbicha> you're right, we don't make the "break my computer" feature of Linux obvious enough ;)
[15:16] <jbicha> a lot of users have to install random stuff from ppa's to get that effect
[15:16] <mdeslaur> haha
[15:17] <mdeslaur> jbicha: so, is that option only when running under unity?
[15:17] <didrocks> sil2100: do you want that we merge? Then, we can redeploy
[15:17] <didrocks> and run only the tests?
[15:17] <jbicha> mdeslaur: I've only been using gnome-shell today; it's a GNOME feature too
[15:17] <didrocks> sil2100: or even better, maybe we can do that stack per stack?
[15:17] <didrocks> sil2100: like, you deploy (without merging)
[15:18] <didrocks> run the stack
[15:18] <mdeslaur> jbicha: I mean, are you implementing mpt's design just for unity sessions, or will it be for gnome too?
[15:18] <didrocks> (with foo)
[15:18] <didrocks> sil2100: and see the result right away?
[15:18] <didrocks> sil2100: want that we do one together?
[15:18] <mdeslaur> jbicha: because just being in the nopasswdlogin should be enough for lightdm, without necessarily disabling the user password and breaking sudo and policykit
[15:19] <sil2100> didrocks: ok, wait one moment, I'll re-merge with trunk and try to re-deploy some smaller stack ;)
[15:19] <mdeslaur> but, I guess that would mean extending accountsservice
[15:19] <mdeslaur> meh
[15:19] <didrocks> sil2100: sure!
[15:19] <jbicha> mdeslaur: my thought was that the Security tab should be Unity only since it duplicates GNOME 3.8's Privacy panel
[15:22] <mdeslaur> jbicha, mpt: ok, I think we don't have the proper infrastructure at the moment to handle a "Log in without a password" option
[15:22] <mdeslaur> jbicha, mpt: ideally, it would just allow logging in a the greeter without disabling the user password completely
[15:22] <mdeslaur> jbicha, mpt: but that would require adding some new apis to accountsservice
[15:23] <mdeslaur> jbicha, mpt: perhaps we should postpone that checkbox for now?
[15:25] <sil2100> didrocks: ok, will re-deploy the media stack, will re-run it for testing (with foo) once done
[15:25] <didrocks> sil2100: ok, looking as well :)
[15:30] <mdeslaur> jbicha: ok, sudo and policykit break because we use "nullok_secure" in our pam config instead of just "nullok"
[15:30] <sil2100> hmmm
[15:30] <sil2100> didrocks: http://<IP_ADDRESS>:8080/view/cu2d/view/Head/view/Media/job/cu2d-media-head-2.2check/88/ <- why?
[15:30] <mdeslaur> jbicha: perhaps a bug could be filed to see if it makes sense to change that
[15:31] <sil2100> didrocks: it didn't fire the autopilot-saucy-daily_release job, strangely?
[15:31] <didrocks> sil2100: ah, nothing to publish ;)
[15:31] <sil2100> But but but but
[15:31] <sil2100> ;p
[15:31] <didrocks> sil2100: in fact, you should run manually the jobs, it's even better :)
[15:31] <didrocks> sil2100: http://<IP_ADDRESS>:8080/job/autopilot-saucy-daily_release/build?delay=0sec
[15:32] <didrocks> release, put "test"
[15:32] <didrocks> stack: name of the stack (it's just for printing)
[15:32] <didrocks> series -> change to saucy :)
[15:32] <sil2100> didrocks: let me check the standard parameters from media then
[15:32] <didrocks> ppa -> the syntax is http://<IP_ADDRESS>:8080/job/autopilot-saucy-daily_release/build?delay=0sec
[15:32] <didrocks> grrr
[15:32] <didrocks> ubuntu-unity/daily-build
[15:33] <didrocks> sil2100: yeah, just use your "packages" and "testspackages"
[15:33] <sil2100> Aaaactually
[15:33] <sil2100> Didn't think about it, but I can test everything like this, heh...
[15:33]  * sil2100 stupid
[15:35] <jbicha> mdeslaur: which package should that bug be for?
[15:35] <didrocks> sil2100: no worry, sometimes, it's easier to go straight to pushing buttons directly :)
[15:35] <sil2100> Ok, I see I have some missing packages, probably deps
[15:36] <mdeslaur> jbicha: pam
[15:36] <sil2100> Fixing!
[15:38] <sil2100> didrocks: hope you don't mind I'll use the autopilot job for my purposes?
[15:39] <didrocks> sil2100: you can even abuse it! nothing needs to run right now :)
[15:43] <didrocks> sil2100: don't add them bindly pleae
[15:43] <didrocks> please*
[15:43] <sil2100> What do you mean?
[15:44] <sil2100> didrocks: with the packages lists, yes?
[15:44] <didrocks> sil2100: yep ;)
[15:45] <sil2100> didrocks: how does the 'extra packages need to be isntalled' work now ;)?
[15:45] <didrocks> sil2100: http://<IP_ADDRESS>:8080/job/autopilot-saucy-daily_release/404/label=autopilot-ati/console
[15:45] <didrocks> it's the same than before
[15:45] <didrocks> /var/log/upstart/otto-setup.log: E: The following additional packages will be installed:
[15:45] <didrocks> and then, you have the diff
[15:45] <sil2100> I know, but this means that without those in the list, it won't work, right?
[15:46] <sil2100> (as long as those make sense)
[15:46] <didrocks> sil2100: right, we juts need to spot if some parts are in universe (for components in main), or if it makes sense to have all those new deps
[15:47] <sil2100> Indeed!
[17:14] <didrocks> good evening everyone :)