[00:00]  * skaet thinks the channel topic is long enough, but is willing to have it added if others feel its important.
[00:01]  * skaet --> EOD
[00:24] <infinity> cjwatson: I'm sure you're asleep by now, but is there any reason why change-override no longer has any output to stdout?
[00:25] <cjwatson> Erm.  It's supposed to.
[00:26] <cjwatson> I wonder if I broke it.
[00:26] <infinity> cjwatson: This just returns without doing anything (AFAICT)
[00:26] <infinity> change-override -c universe cl-speech-dispatcher speech-dispatcher-doc-cs speech-dispatcher-festival speech-dispatcher-flite
[00:26]  * cjwatson experiments.
[00:27] <infinity> (Everything in i386 in that source landed in main, so there's an arch skew, I wonder if that relates?)
[00:27] <micahg> infinity: in the mean time, can you poke precise for backports?
[00:27] <cjwatson> Oh, hahaha
[00:27] <infinity> Also, did someone make the NEW queue override handling worse than it used to be?
[00:28] <cjwatson> Removed a *little* too much when moving stuff to a common module
[00:28] <slangasek> skaet: vanguards> wasn't that supposed to be split out into a new page?
[00:28] <slangasek> (http://wiki.ubuntu.com/SRUTeamProcess)
[00:28] <infinity> Cause, my guess as to how the entire source landed in main is perhaps that someone NEWed its one new arch:all binary to main via the queue.  Which used to only act on the actually "new" binaries.
[00:28] <cjwatson> Not aware that NEW override handling's been changed particularly.
[00:28] <cjwatson> infinity: change-override r496 *cough*
[00:29] <infinity> micahg: Sure.
[00:29] <micahg> thanks
[00:29] <skaet> slangasek,  yes, more to go onto that page though, and the 12.04.1 team was asking for pointers this morning, so I put it there for now.
[00:29]  * skaet will move it.
[00:29] <infinity> micahg: What am I poking?
[00:29] <slangasek> skaet: ok
[00:30] <micahg> infinity: NEW for 2 sources and unapproved for 1 (should all be at the top)
[00:30] <infinity> True for the NEW ones anyway.
[00:30] <micahg> infinity: jquery :)
[00:30] <micahg> right, of course, people have the audacity to do work!
[00:42]  * xnox ponders, how do archive admins 'process' their queue if https://bugs.launchpad.net/~ubuntu-archive/+subscribedbugs timesout
[00:43] <infinity> Try harder until there's a hot cache of all the queries involved.
[00:43] <infinity> And then curse people who write massive(ly inefficient) SQL-driven systems.
[00:43] <cjwatson> xnox: lp-shell
[00:44] <xnox> ok
[00:44] <cjwatson> >>> ua = lp.people["ubuntu-archive"]
[00:44] <cjwatson> >>> for task in ua.searchTasks():
[00:44] <cjwatson> ...     print task.bug.id, task.bug.title
[00:44] <xnox> cjwatson: can you merge aptitude or shall I upload the patch to fix FTBFS-gcc4.7, it's one of the last 7 packages in boost1.49 transition
[00:44] <xnox> let me try that ;-)
[00:45] <cjwatson> I told you, it's waiting for the pristine-tar xz fix
[00:45] <xnox> sorry, forgot.
[00:45] <cjwatson> Feel free to upload a non-merge patch in advance of that if you prefer
[00:45] <xnox> ok. thanks. will do.
[00:46] <infinity> cjwatson: Oh, haha.  I just read your change-override diff.
[00:46] <infinity> cjwatson: Oops.
[00:46] <cjwatson> Yeah, slightly aggressive refactoring
[00:47] <micahg> and last thing keeping boost1.46 in main :)
[00:48] <micahg> xnox: mpi-source can go now FWIW
[00:48] <cjwatson> skaet: I can auto-sync again, yes?
[00:49] <skaet> cjwatson,  auto-sync is good
[00:49] <cjwatson> Cool
[00:49] <xnox> micahg: true. but I wanted one bug and get rid of them together and not bother archive admins to much. or shall I split it...
[00:49] <micahg> xnox: nah, don't need to split
[00:49] <xnox> micahg: ok, one confirmed the other one incomplete?
[00:50] <micahg> yeah, sounds good
[00:51] <infinity> micahg: Can "go" as in "removed", or "to universe"?
[00:51] <infinity> Cause the latter, we get told about without bugs.
[00:51] <infinity> But I'm all for removing stuff. ;)
[00:51] <micahg> infinity: the mpi-source has no more dependencies AFAICT
[00:52] <micahg> the 1.46 mpi source that is :)
[00:52] <infinity> Full source name?
[00:52] <micahg> boost-mpi-source1.46
[00:52] <micahg> bug #1019090
[00:52] <ubot2> Launchpad bug 1019090 in boost-mpi-source1.46 "Please remove boost1.46 from Quantal" [Low,Confirmed] https://launchpad.net/bugs/1019090
[00:55] <infinity> Removed.
[00:56] <xnox> infinity: bug 1019096
[00:56] <ubot2> Launchpad bug 1019096 in mongodb "please remove 1:2.0.4-1ubuntu2 mongodb armel only binaries from quantal" [Undecided,Confirmed] https://launchpad.net/bugs/1019096
[00:56] <micahg> xnox: why would you do that?
[00:57] <infinity> xnox: Erm, are you sure about that?
[00:57] <infinity> xnox: Is this gcc 64-bit atomics?
[00:57] <xnox> discussed with doko and folks from #linaro
[00:57] <infinity> xnox: If so, it's waiting on a buildd kernel upgrade and it'll magically work again.
[00:59] <xnox> current quantal gcc toolchain for armel does not define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
[01:00] <xnox> is that the same?
[01:00] <xnox> i'll check with doko again then.
[01:01] <xnox> infinity: how would I find out about buildd kernel upgrades and things that will magically start working again?
[01:01] <infinity> That should be defined...
[01:02] <infinity> Since GCC uses software-driven atomics on older CPUs.
[01:02] <infinity> I thought.
[01:02] <infinity> Maybe I'm getting two issues confused.
[01:02] <xnox> doko> xnox, pm215, ramana: it's only defined for armv7. armel in quantal is armv5
 doko, that's bizarre. The sync primitives should be supported irrespective of the level of the architecture.
 doko, on armv5 the sync primitives end up calling the kernel helper functions.
 doko: i will leave the said package FTBFS on armel as a hint that it's a TODO item
[01:03] <infinity> Yeah, exactly what ramana said.
[01:03] <infinity> If it's not defined, that's probably a toolchain bug.
[01:04] <xnox> so.... should I file a bug about it... or do you think doko got the hint from ramana?
[01:04] <infinity> File a GCC bug and quote your IRC log there.
[01:04] <infinity> Cause we have full GCC atomic support (with kernel helpers) and all ARM targets.
[01:05] <infinity> Or, all the ones we care about.
[01:05] <infinity> Though they won't *work* on armel until we upgrade the buildd kernels. :P
[01:05] <infinity> But that's only an issue for testsuites and builds that run their own code.
[01:05] <infinity> Since it compiles correctly, and runs in quantal just fine.
[01:06] <xnox> ok
[01:06] <xnox> mongodb does run their own code as smoke test.
[01:06] <xnox> not going to disable the testsuite
[01:06] <infinity> Sure, so it'll fail anyway, even with a fixed compiler, but we know the solution to that, and it's being worked on.
[01:06] <infinity> Removing arches isn't the answer, fixing the bugs is.
 ramana, but gcc -march=armv5 -E -dM - </dev/null|grep SYNC
[01:08] <xnox> prints nothing
[01:13] <xnox> infinity: filed as bug 1019098
[01:13] <ubot2> Launchpad bug 1019098 in mongodb "armel quantal please define sync primitives" [Undecided,Confirmed] https://launchpad.net/bugs/1019098
[01:13] <xnox> helpful, it is against gcc-4.7 package as well
[01:14] <infinity> xnox: Make sure some Linaro GCC hackers have it on their radar. :P
[01:14] <infinity> xnox: If you've been talking to some.
[01:14] <xnox> ok :P
[01:14] <infinity> Michael Hope would be a good choice, if he's jumped into the conversation.
[01:15] <infinity> He'll probably know straight up if it's a bug or a feature, and what to do about it.
[01:15] <xnox> matthias vs linaro team
[01:15] <infinity> (michaelh on IRC)
[01:15] <xnox> ok, thanks.
[01:15] <xnox> may I name you as a referral?
[01:16] <infinity> Sure. :P
[01:16] <infinity> He can hit me at the next Connect.
[01:16] <infinity> It'll be grand.
[02:20] <xnox> about pyopencl see bug 763457 as well
[02:20] <ubot2> Launchpad bug 763457 in nvidia-graphics-drivers "please provide opencl-icd virtual package" [Medium,Confirmed] https://launchpad.net/bugs/763457
[09:50] <cjwatson> zul: Rejecting one of the two python-cinderclient uploads in NEW while I look over the other one
[09:51]  * ogra_ wonders if we cant do better than sending mails twice to -changes for every package that moved from $dev-proposed to $dev
[09:51] <ogra_> especially since they are all signed by the same person now
[09:51] <cjwatson> Yes, we probably can
[09:52] <cjwatson> At some point
[09:52] <ogra_> heh
[09:59] <Daviey> ogra_: distributed procmail rules? :)
[10:00] <ogra_> Daviey, well, i think we should fix that at the source :) save bytes !!
[10:29] <ogra_> hmm, are live builds still on manual ?
[10:48] <jibel> stgraber, quantal dailies have not been published to the tracker
[11:33] <Daviey> jibel: I think i know why that is...
[11:33] <Daviey> Hmm, i do not.
[11:34] <Daviey> they should have been..
[13:55] <stgraber> jibel: let me check quickly
[13:58] <stgraber> /srv/cdimage.ubuntu.com/bin/post-qa: 95: /srv/cdimage.ubuntu.com/ubuntu-archive-tools/post-image-to-iso-tracker.py: not found
[13:58] <stgraber> looks like Colin broke the script ;)
[13:58]  * stgraber fixes
[14:00] <stgraber> jibel: can you manually post them? or balloons? I don't see an easy way for me to rerun that part automatically
[14:02] <stgraber> Daviey: fixed (FYI, that kind of failure typically gets logged at the end of the cd-build-log)
[14:29] <Daviey> stgraber: thanks
[14:36] <stgraber> cjwatson: I update post-qa after the rename of post-image-to-iso-tracker.py to post-image-to-iso-tracker (noticed when we got no daily on the tracker today ;)), are you aware of any other script that should be updated?
[14:37] <stgraber> *updated
[14:37] <jibel> stgraber, thanks you
[14:37] <jibel> balloons, can you do the update ?
[14:38] <cjwatson> stgraber: Oh, thanks, good point
[14:38] <cjwatson> stgraber: I updated all the ones I remembered about ...
[15:43] <ScottK> I just accepted a new SRU for bzr that fixes a regression from their microversion update.  Since this is a targeted change to fix a regression in a previous SRU, how long to we let it bake after verification before copying to -updates?
[15:50] <skaet> ScottK,  good question.   Standard 7 days doesn't quite seem appropriate, since its a fix for a regression on an SRU.   How well validated is it?
[15:51] <ScottK> None yet.  It's still building.  I just accepted it.
[15:51] <xnox> skaet: it's a revert of affending patch. Such that the original 2 bugs that the patch was fixing should now be reopened for an SRU again.
[15:53] <skaet> xnox,  good point,  we don't want to overlook that.
[15:57] <ScottK> jelmer already reopened the original bug.
[15:57] <skaet> ScottK,  once the fix is validated, and the original bugs are reopened,  we should probably get it released rather than waiting for the bake in period.   Only caveat, is with the holiday's approaching next week,  this sort of thing should be on Monday though, since coverage may be light for a good part of next week.
[15:57] <skaet> (since we don't usually do it on Fridays)
[16:06] <slangasek> ScottK, skaet: I would publish it as soon as it's been spot-tested and confirmed to fix the stated issue
[16:06] <slangasek> Friday or not
[16:06] <ScottK> Makes sense to me.
[16:06] <skaet> slangasek, ok
[16:08] <ScottK> It's built on i386.  I can test it.
[16:18] <ScottK> Works.
[16:20] <ScottK> slangasek: I verified it, so once it finishes building, I'll release it.
[16:20] <slangasek> ScottK: sounds good
[16:40] <Daviey> ScottK: If you accept it today, are you happy to be on point for (unlikely) regressions over the weekend?
[16:41] <ScottK> Daviey: I'm always happy to deal with problems when I'm around.
[16:42] <ScottK> (I don't think SRU team people in particular or developers in general should only worry about such significant issues like release regressions during certain hours).
[16:43] <Daviey> ScottK: right.. the reason i ask is that in previous cycles there have been regressions introduced by SRU's over the weekend.. with nobody with access to deal with it.
[16:43] <Daviey> squid was a good example
[16:44] <Daviey> (Which is why i pushed for no SRU's on Friday's :)
[16:44] <cjwatson> Access should be less of a problem these days
[16:44] <cjwatson> Back then only Canonical employees could publish updates
[17:20] <cjwatson> MIR team folks: would anyone object to me moving fonts-lklug-sinhala, fonts-sil-nuosusil, and fonts-ukij-uyghur to main without MIRs?  They're all installed by language-selector for various languages, and in particular moving fonts-lklug-sinhala to main is required to fix bug 1015483
[17:21] <ubot2> Launchpad bug 1015483 in ubuntu-meta "ubiquity-dm: 2 language names wrongly displayed (missing font?)" [High,In progress] https://launchpad.net/bugs/1015483
[17:28] <slangasek> mksh MIR> wtf
[17:33] <infinity> cjwatson: I don't think anything more than a verbal "yeah, go for it" is required for font packages, as long as they're simple and (hopefully) unmodified from Debian so there's no maintenance burden.
[17:36] <cjwatson> infinity: We have a few that are modified for "squeeze more into desktop" reasons, but these aren't among them.
[17:36] <cjwatson> infinity: So is that a verbal "yeah, go for it"? :-)
[17:36] <infinity> cjwatson: Yeah.  Go for it. :P
[17:37] <cjwatson> Great, thanks.
[17:37] <infinity> If we find a security bug in a font tomorrow, I'll be a sad panda.
[17:37] <cjwatson> Oh, promoted the udebs and transitionals and such by mistake.  I'll demote them later.
[17:37] <cjwatson> (Can't remember if rapid promotions/demotions are still a problem ...)
[17:38] <infinity> I *think* it gets it right now, but I don't remember...
[17:38] <infinity> And I always take the paranoid approach and wait a cycle.
[17:38]  * slangasek works on kicking pdksh out of main
[17:38] <infinity> We probably should sort out, one day, how much of our residual paranoia can go away, and what bugs still need fixing. :P
[17:38] <cjwatson> Kind of what I've been doing :-)
[17:39] <cjwatson> Ish
[17:39] <infinity> slangasek: But, but, I'm sure it's the prefered shell for 1 in 20000 users.
[17:39] <slangasek> infinity: that has nothing to do with why it's in main
[17:39] <infinity> slangasek: rbuild-dep was my assumption, I hadn't looked yet.
[17:40] <slangasek> yep
[17:40] <slangasek> *spurious* rbuild-dep
[17:40] <slangasek> wtf people
[17:41] <cjwatson> You filed bug 180218, but I'm not entirely sure that's it.
[17:41] <ubot2> Launchpad bug 180218 in launchpad "override mismatch race needs to be fixed" [High,Triaged] https://launchpad.net/bugs/180218
[17:42] <cjwatson> stgraber: Testing a fix for livecd-rootfs and -proposed now
[17:42] <cjwatson> I guess I'll need to SRU that in order to get it into the livefs build chroots
[17:42] <cjwatson> infinity: You don't happen to know whether the livefs build chroots can get livecd-rootfs installed from -proposed, do you?
[17:42] <cjwatson> It would save time.
[17:44] <infinity> cjwatson: I'm sure it could be arranged.
[17:44] <cjwatson> Can you do it or do I need to ask some bit of IS?
[17:44] <infinity> cjwatson: But We could also just fast-track an SRU.
[17:44] <cjwatson> I need to get an updated BuildLiveCD put in place anyway.
[17:45] <cjwatson> infinity: Which raises the secondary question of whether the livefs build chroots have -updates switched on :-)
[17:45] <infinity> cjwatson: It's a webops-ish thing.  And be sure to mention the BuildLiveCD thing explicitly, they need to jam that into puppet and let is propagate.
[17:46] <infinity> cjwatson: I *think* we made sure they had updates on a while ago.  But memory's failing in my old age, and maybe that wasn't for precise.
[17:46] <infinity> s/let is/let it/
[17:46] <cjwatson> If this test build looks good then I might see if I can get somebody to do it for me before the week dies.
[17:46] <cjwatson> Assuming I'm not dragged off for evening stuff before then.
[17:47] <cjwatson> (I kind of promised stgraber/jibel it'd be done before EOW)
[17:48] <stgraber> cjwatson: long weekend here, so I won't notice until Tuesday at least ;)
[17:51] <infinity> stgraber: Oh hey, Canada Day is upon us, I hadn't even noticed.
[17:52] <infinity> stgraber: Also, you're in Quebec.  You can't celebrate Canada Day.  Get your own holidays (of which you appear to have many).
[17:52] <stgraber> infinity: well, it's your fault for not having Alberta day ;) I'm quite enjoying having two long weekends in a row, the Edubuntu todo list is getting much shorter thanks to that
[17:53] <highvoltage> it will be my 3rd long weekend in a row.
[17:54] <slangasek> oh bah, of course the things that use pdksh are using it under the name ksh, not pdksh
[17:55] <slangasek> so yeah, not so spurious :(
[17:55] <cjwatson> What on earth do things still need ksh for in this day and age?
[17:55] <cjwatson> And are they all maintained by the mksh maintainer? :-)
[17:56] <infinity> People actually script in ksh?
[17:57] <slangasek> graphviz, shunit2 both reference ksh
[17:57] <ScottK> bzr's out.
[17:57] <slangasek> as to why, well...
[17:57] <slangasek> ScottK: cheers
[17:57] <infinity> Is it 1978?  Did I sleep on the wrong side of my flux capacitor?
[17:58] <slangasek> infinity: so entertainingly, if you don't have pdksh the only part of graphviz that doesn't build is the ruby bindings
[17:58] <infinity> slangasek: That seems like an acceptable sacrifice. :P
[17:59] <infinity> slangasek: (But surely, the offending bit can be rewritten in POSIX sh instead)
[17:59]  * slangasek hands infinity the knife
[17:59] <infinity> slangasek: Like, with nearly zero effort.
[17:59] <slangasek> more effort than I'm putting in today
[17:59] <cjwatson> Riddelll: Hm, so do you know why Kubuntu currently has both kdm and lightdm installed?
[17:59] <slangasek> let the MIR team sort it out :P
[18:00] <infinity> Well, I have no issues with swapping pdksh and mksh in main and letting the status quo continue for Right Now, but fixing the rbuild-deps seems generally sane anyway.
[18:01] <cjwatson> Riddelll: That's what's breaking ubiquity-dm - it's "start on (starting kdm or starting lightdm)" (among other things).  The lightdm job starts but does nothing because it isn't the default DM, but that's enough to let ubiquity start just after kdm starts, and then fail because kdm has already managed to start an X server.
[18:01]  * infinity wonders if the ksh dependency is/was perhaps a bizarre side-effect of Sun's /bin/sh sucking so hard that they had to pick something else to be "cross-platform".
[18:02] <infinity> It's amazing how many things in the UNIX world I can blame on Sun's /bin/sh, if I put my mind to it.
[18:02] <slangasek> lamont: postfix decided to stop resolving names, your package is making my bug reports late for the Debian freeze :P
[18:03] <ScottK> But since you can't report the bug on postfix, it seems like a fine situation for lamont.
[18:05] <ScottK> cjwatson: I was busy with work this week, so I'm not sure, but I suspect Kubuntu is accidentally half-switched.  I believe there's an intent to switch.
[18:06] <slangasek> ScottK: restarting postfix fixed it
[18:07] <slangasek> which seems to imply it's well named
[18:07] <ScottK> Meh.  No fun.
[18:08] <cjwatson> ScottK: Right, if the job gets finished then I think this will stop being a problem.
[18:08] <cjwatson> It's not ideal that it has this result, but it's pretty hard to fix.
[18:09]  * ScottK wonders where Riddelll is today?
[19:00] <cyphermox> hey; I'd like to use quantal-proposed to start the transition of evolution-data-server without making too many things uninstallable; is there any more coordination I should do than letting the release team know? ;)
[19:01] <infinity> cyphermox: That's good enough for me.
[19:01] <infinity> cyphermox: (Didn't we just break e-d-s two weeks ago?)
[19:01] <cyphermox> (yes we did)
[19:01] <cyphermox> infinity: ok. then that's a head's up to not take e-d-s from -proposed to -release just now, once I upload it
[19:02] <micahg> cyphermox: please coordinate with chrisccoulson for thunderbird
[19:02] <cyphermox> micahg: yes
[19:04] <cyphermox> might just end up being monday or tuesday
[19:08] <infinity> cyphermox: If you start it today, helpful community types (like me, with a different coloured hat) just may finish the transition for you.
[19:08] <infinity> cyphermox: Well, with the possible exception of thunderbird.
[19:09] <cyphermox> right, but I'm a little worried about breaking too many things on a friday afternoon
[19:09] <infinity> Breaking things in proposed is entirely acceptable.
[19:09] <infinity> FSVO "break".
[19:09] <cyphermox> and I'm working on setting up the transition tracker locally to see what I'm doing along the way, too
[19:10] <cyphermox> e.g. teaching it clumsily to care about proposed
[19:11] <Laney> We need to teach the deployed instance to do this too. It amounts to catting the Packages/Sources files together and doing away with the in-ben download step, as cyphermox tested. :-)
[19:11] <cyphermox> Laney: I'll have a script for you in a minute
[19:12] <Laney> get cjwatson to give you the cron script and hack it into that :P
[19:13] <cyphermox> I guess
[19:14] <cyphermox> infinity: also, I was trying to ask chrisccoulson about thunderbird, hence why I said monday or tueday, when he's aware of my plan
[19:14] <infinity> cyphermox: Fair enough.
[19:14] <Laney> Looks like ubuntu-archive@lillypilly already has a mirror, so that's easier
[19:14] <infinity> Laney: If by mirror, you mean the real thing.
[19:14] <Laney> it's called mirror.
[19:15] <Laney> /home/ubuntu-archive/mirror/ubuntu/dists/quantal/
[19:15] <infinity> Oh, you mean the mirror of the archive.
[19:15] <infinity> I thought you meant a "mirror" of the tracker.
[19:15] <Laney> a mirror to check it's hair is OK today
[19:15] <Laney> its
[19:16] <Laney> I know the tracker lives there — that's why I was checking for a mirror :-)
[19:17] <infinity> Yeah, yeah.  I'll stop being "helpful". ;)
[19:32] <cyphermox> Laney: so I checked with zlib, it does seem like when you cat -proposed over -release, the -proposed version is the one that gets tracked
[19:40] <Laney> cyphermox: yay


[00:17] <Guest71016> hi
[00:17] <Guest71016> goodmornig
[00:17] <Guest71016> ihd installed kde plasma desktop de on ubantu ...then i restartd pc and login loop stated ..i cant login..
[00:27] <Guest71016> hello good morning
[00:27] <Guest71016> anybody is here to help..?


[03:50] <robru> ugh
[03:52] <robru> jamesh: I'm here, let me dig into this
[03:53] <jamesh> robru: if it helps, the previous build in the silo I hadn't added anything to debian/changelog
[03:53] <jamesh> with this rebuild, I did (I had added some API, so wanted to bump the version number)
[03:53] <robru> jamesh: I made some train changes recently that probably broke it, just investigating
[03:55] <jamesh> it looks like it has uploaded the Xenial source package to the silo, but not the Vivid one
[03:56] <robru> jamesh: yeah the vivid half of dual silos is being a bit weird the last couple days
[03:56] <robru> jamesh: it also didn't build anything for vivid
[03:59] <jamesh> robru: thanks for looking into this so quickly
[03:59] <robru> jamesh: you're welcome!
[04:00] <robru> jamesh: huh well that's strange, I just retried it with debug logging on and it looks like it's working now (it didn't create the vivid copy before but it did now... let's see if it builds)
[04:10] <robru> jamesh: huh well it totally worked.
[04:18] <jamesh> yep.  Looks like each package has successfully finished building on some architectures.
[06:11] <robru> please ping me if anything explodes, i should be around for a few more hours
[07:03] <robru> tvoss: you don't need to assign after changing mps anymore
[07:03] <tvoss> robru, ah, cool
[09:36] <popey> davmor2, setting that task to qa failed and will leave it for a bit, and then flip it back a bit later
[09:57] <robru> tvoss: sorry about that, train bug. trying again: https://ci-train.ubuntu.com/job/ubuntu-landing-047-1-build/76/console
[09:57] <robru> Mirv: sil2100 ^^ hmm it's happening again
[09:58] <robru> second try seems to work. very strange
[10:05] <Mirv> hmm
[10:07] <morphis> sil2100, Mirv, robru: any time to merge https://requests.ci-train.ubuntu.com/#/ticket/522 ?
[10:08] <robru> morphis: needs a core dev to publish
[10:08] <morphis> ah, right
[10:08] <morphis> let me ping one
[10:11] <morphis> robru: btw. if I get upload rights for a single package to the archive can I then upload to a silo for that package too?
[10:16] <robru> morphis: eh, no, only ci-train-ppa-service (aka trainguards) and core dev can upload to silos.
[10:17] <morphis> ok
[10:17] <robru> morphis: "upload to silos" is unfortunately a feature of launchpad rather than a feature of the train so not much I can do about that
[10:17] <morphis> robru: before I file a bug about that, basically I had a active discussion with cyphermox about this on friday
[10:18] <morphis> the outcome was: is it possible that we do MP based landings with citrain/silos which doesn't touch the changelog but take it as it is in the MP?
[10:18] <robru> morphis: if you write your own debian/changelog the train will not touch it
[10:19] <morphis> robru: ah, so that already works, interesting
[10:19] <morphis> robru: it will also not modify the version number?
[10:19] <robru> morphis: or at least that was once the case, it's possible that regressed, I don't think that bit of code is well tested.
[10:19] <robru> morphis: no it will always mangle the version number even if you write your own changelog entry.
[10:19] <robru> morphis: there's a different way to stop it mangling the version number
[10:20] <morphis> which one?
[10:20] <sil2100> There was a flag in debian/control in the past that made the train not mangle the version
[10:20] <sil2100> robru: is it still supported?
[10:21] <robru> morphis: in debian/control you have to do 'X-Auto-Uploader: no-rewrite-version'
[10:21] <robru> morphis: but I don't really recommend using that, it's more hassle than it's worth. if you let the train generate the number you can rebuild more easily. using that means you have to push a new commit for every rebuild you want to do
[10:21] <sil2100> Ok, so it's still supported, yey
[10:22] <morphis> robru: the background for this is that I really would like to do MP based landings for bluez
[10:22] <morphis> but cyphermox (and other core devs) don't want the mangled version numbers in the archvie
[10:22] <morphis> which makes sense
[10:22] <robru> morphis: MPs typically only work for projects that we are the upstream for.
[10:22] <morphis> as bluez isn't our upstream
[10:23] <morphis> robru: I know, but what if we take the idea a bit further as this is really something which improves our quality and makes reviewing a lot easier
[10:23] <robru> morphis: "a bit further"? what else do you need? train does support not mangling the version
[10:24] <morphis> robru: yes, I just meant taking it a bit further than only using it to land canonical upstream through MPs
[10:24] <robru> morphis: to do an MP based merge you need to have the packaging inlined in the branch
[10:24] <robru> morphis: could be a bit tricky as currently some security-sensitive code makes the assumption that MPs=canonical so that would need to be tweaked if we started doing MPs for third party stuff
[10:25] <morphis> robru: generally landing through MPs for bluez works fine
[10:25] <robru> morphis: also train is really sensitive to the packaging being just so, easy when we're upstream, harder for rando packages
[10:25] <morphis> we did the last landing this way
[10:25] <morphis> robru: I wouldn't recommend this for all packages or the general way of doing landings
[10:26] <robru> morphis: right well I'm open to it, feel free to file a bug if you have specific problems
[10:26] <morphis> in my particular case I want a quality process which enables us to do dual-landings for bluez where all sides (desktop, touch, ..) can comment/review the landing and say yes or no
[10:26] <morphis> robru: let me try the field in debian/control
[10:29] <robru> morphis: yeah MPs are obviously way more transparent than manual source uploads.
[10:29] <morphis> robru: exactly
[10:37] <robru> alright, nearing 3AM, night folks ;-)
[10:56] <tvoss> robru, sil2100 mind having a look here: https://launchpadlibrarian.net/227352402/buildlog_ubuntu-xenial-ppc64el.trust-store_2.0.0%2B16.04.20151123.1-0ubuntu1_BUILDING.txt.gz
[10:56] <tvoss> ?
[10:56] <sil2100> tvoss: looking
[10:58] <sil2100> tvoss: hmm... looks like some issue with mesa-common-dev in ppc64el
[10:58] <tvoss> sil2100, yup
[10:59] <sil2100> dpkg-deb (subprocess): decompressing archive member: lzma error: compressed data is corrupt
[10:59] <sil2100> WTH
[10:59] <sil2100> Let me check if it's corrupt here as well
[11:01] <sil2100> tvoss: archive looks fine here, let's try re-building, maybe it was just some random corruption on the machine
[11:01] <sil2100> tvoss: where was that build from?
[11:01] <tvoss> sil2100, silo 21
[11:01] <tvoss> sil2100, kicked rebuild
[11:02] <sil2100> I see it built successfully, as I see no failure now
[11:53] <morphis> robru: seems like that worked perfectly: https://ci-train.ubuntu.com/job/ubuntu-landing-054-1-build/37/console
[11:58] <sil2100> jhodapp: hey! I just checked the seeds and from what I see no seed changes will be needed for the new media-hub
[11:59] <sil2100> jhodapp: the seeds only depend on the media-hub package which pulls in the other deps, so it should simply pull in the new 4 libaries by default after publishing since the deps have been modified
[12:19] <boiko> rvr: hi, need any help with silo 25 testing? or is it under control?
[12:21] <rvr> boiko: Currently under control. If I have any doubt, I'll ping you, thanks :)
[12:21] <boiko> rvr: cool, thanks :)
[12:23] <popey> jibel, my music-app card is still in trello under 'failed' - can it be moved pls?
[12:23] <popey> I worry nobody will look at it again
[12:24] <popey> oooh! it's in both!
[12:24] <popey> jibel, /ignore popey
[12:26]  * sil2100 lunch
[12:28] <Mirv> :)
[12:32] <morphis> robru: ping
[13:23] <jhodapp> sil2100, awesome thanks for looking into that
[13:27] <rvr> boiko: ping
[13:29] <boiko> rvr: pong
[13:29] <rvr> boiko: I have a Bluetooth speaker paired. When I do a call to the device, the ring tone is played on the phone and not on the speaker.
[13:29] <boiko> salem_: ^
[13:30] <boiko> salem_: can't remember if that's expected or not
[13:30] <salem_> rvr, I believe that's expected
[13:30] <rvr> salem_: "Ringing should go by default only to wired headset if connected"
[13:30] <boiko> rvr: I think we only play in both outputs when using wired headsets
[13:31] <boiko> rvr: yes, wired, not bluetooth
[13:31] <rvr> Ah, wired
[13:31] <boiko> rvr: :)
[13:31] <rvr> The call then uses the speaker
[13:31] <boiko> rvr: for wired headset it should ring on both the headphone and the speaker
[13:32] <rvr> and when I do a call using the device, the speaker is also used
[13:32] <rvr> The only thing that doesn't use the speaker is the ring tone when receiving a call
[13:33] <boiko> rvr: you mean in the bluetooth case?
[13:33] <rvr> boiko: Right
[13:33] <rvr> I don't have a wired headset
[13:34] <boiko> rvr: I think some regular wired headphones should work too (or they used to the last time I tried)
[13:52] <xavigarcia_lunch> jibel: ping
[13:53] <xavigarcia> davmor2: hey there! Just to double check you received my previous message (sometimes my IRC does weird things)
[13:54] <davmor2> xavigarcia: possibly not
[13:54] <davmor2> xavigarcia: I saw your message on the trello card though
[13:54] <xavigarcia> davmor2: oh, ok... it was just about that
[13:54] <jibel> xavigarcia, pong
[13:55] <xavigarcia> jibel: hey! I've updated the indicator sound silo, to avoid those ugly notifications on phone calls
[13:55] <davmor2> xavigarcia: I'll get back to you when I have some time
[13:57] <xavigarcia> davmor2: ok... thanks!
[13:58] <boiko> rvr: just flashed a krillin with silo 25 here and confirmed that with a wired headset it plays the ringtone on both the speaker and the headphones
[13:58] <rvr> boiko: Great, thanks
[13:59] <rvr> boiko: But it doesn't happen with my Bluetooth speaker
[13:59] <rvr> boiko: With OTA8, something is played on the speaker
[14:00] <boiko> salem_: do you have a bluetooth speaker to try it there?
[14:01] <boiko> rvr: we didn't change any of that in the code, so, if it is broken now, it might be because of some other landing, maybe the recent bluez changes?
[14:02] <boiko> rvr: can you just clarify what behavior you are expecting (and that you had in OTA8 on your device)?
[14:02] <rvr> boiko: According to davmor2, it should make a sound on both devices
[14:03] <rvr> He tested bluez5
[14:03] <boiko> rvr:/me checks the code, but I don't think that was implemented in our side.... let me see
[14:03] <boiko> salem_: ^
[14:04] <salem_> rvr, your bluetooth speaker has no hfp support probably
[14:04] <sil2100> kenvandine, cyphermox: hey guys!
[14:04] <cyphermox> sil2100: hey
[14:04] <sil2100> kenvandine, cyphermox: or actually, let me move this to #ubuntu-devel
[14:04] <salem_> rvr, I suppose you only hear the ringtone if your bluetooth device has hfp
[14:04] <rvr> I checked OTA8, and some kind of wait sound is played in the speaker
[14:06] <salem_> rvr, then it must be something related to the bluez change. morphis can probably comment on that.
[14:06] <rvr> salem_: I see
[14:06] <salem_> rvr, if that's the case, you can try with an older image, and if it works, we have to file a bug against bluez I think
[14:07] <boiko> rvr: in any casem the behavior you see with silo 25 should be the same as the one you see using latest packages from vivid overlay
[14:07] <salem_> rvr, yep, we haven't changed the ringtone behavior in any of the MR's in that silo.
[14:08] <davmor2> rvr, boiko: morphis can confirm but in my testing the phone always rang and then the headset made whatever tone it defaults to, Some ring like a phone others just beep
[14:13] <morphis> rvr, salem_, boiko: lets clarify one thing first:
[14:14] <morphis> if we're connected on the HFP profile we just send the indication and whatever ringtone the handsfree-device has is played, we don't stream any ringtone audio to the BT device
[14:14] <morphis> if we're to A2DP only device audio is forwarded to the BT device
[14:14] <morphis> which includes also the ringtone
[14:18] <salem_> morphis, thanks for the clarification.
[14:19] <morphis> salem_: so what are you seeing on your side?
[14:21] <salem_> morphis, I haven't tested yet. but rvr reported he is not hearing the ringtone in the bluetooth speaker, which according to your explanation it should be played.
[14:22] <morphis> salem_: make sure the speaker supports only A2DP
[14:22] <morphis> if it supports both HFP and A2DP you will only hear whatever the speaker wants to play on an incoming call
[14:26] <salem_> morphis, yes, from what I understood his device is A2DP only, and nothing is being played.
[14:27] <morphis> rvr: can you follow the steps under "Generating log files with debugging information" on https://wiki.ubuntu.com/DebuggingBluetooth and share /var/log/syslog after a reboot and reproducing this?
[14:27] <rvr> morphis: Ok
[14:29] <morphis> rvr: thanks!
[14:39] <rvr> morphis: There is no /etc/init/bluetooth.override
[14:39] <rvr> NOTE: If /etc/init/bluetooth.override doesn't exist use the following command instead
[14:41] <davmor2> rvr: so use the other command ;)
[14:41] <morphis> rvr: :)
[14:41] <rvr> I read that later, sorry :)
[14:41] <morphis> rvr, davmor2: once ota9 is released the .override line will go away :)
[14:47] <bfiller> sil2100: can you force merge silo 24 please (camera-app) - stuck in xenial proposed
[14:47] <rvr> morphis: <morphis> rvr: :)
[14:47] <rvr> Ups
[14:47] <rvr> morphis: http://paste.ubuntu.com/13477057/
[14:48] <sil2100> bfiller: on it, let me look at teh reason quickly
[14:48] <bfiller> sil2100: thanks
[14:49] <sil2100> bfiller: hmmm
[14:50] <sil2100> bfiller: give me a few mins, the excuses page didn't get updated yet so I don't see why it's stuck
[14:50] <bfiller> sil2100: sure, thanks
[14:50] <seb128> bfiller, why do you think it's stucked?
[14:50] <sil2100> But I see the package's been there for just 20 minutes
[14:50] <seb128> bfiller, it has been uploaded 15 minutes ago
[14:50] <sil2100> So maybe it's just migrating
[14:55] <bfiller> seb128, sil2100: yeah maybe, but figured it was stuck or blocked as it migrated immediately into vivid+overlay
[14:56] <bfiller> I'm just impatient I guess
[14:56] <bfiller> as I want to release a click bult from trunk
[14:57] <sil2100> It should be quick I suppose, I see it's a valid candidate and output doesn't say anything bad as well
[14:57] <sil2100> Should migrate with the next tick possibly
[14:58] <seb128> bfiller, the mps got merged so I guess it migrated
[14:58] <seb128> just got emails about one of my fix changing to merged
[14:59] <alex-abreu> trainguards having issues w/ silo 45 https://ci-train.ubuntu.com/job/ubuntu-landing-045-1-build/107/console
[15:04] <rvr> morphis: boiko: I created a bug here https://bugs.launchpad.net/canonical-devices-system-image/+bug/1519007
[15:05] <boiko> rvr: thanks
[15:06] <seb128> rvr, morphis, boiko, is that a variant from https://code.launchpad.net/~tiagosh/telepathy-ofono/play_ringtone_speakers/+merge/276312 ? the bug linked to that mp is still open
[15:07] <Saviq> robru, hey ho, did anything change in the train recently that could cause https://ci-train.ubuntu.com/job/ubuntu-landing-005-1-build/219/console when using your -gles packaging approach? why would the qtmir tarball be missing?
[15:08] <boiko> seb128: nops, that's for wired headset, that's fixed already
[15:08] <seb128> k
[15:09] <morphis> rvr: thanks
[16:36] <Saviq> trainguards, I can't build https://requests.ci-train.ubuntu.com/#/ticket/690, it forces the -gles packages for qtmir and qtubuntu, but something must've changed and robru's trick for building those out of the same source doesn't work, qtmir tarball is not found when -gles is building :/
[16:36] <popey> congratulations sil2100
[16:49] <sil2100> popey: thanks! :)
[16:49] <sil2100> Saviq: hmm
[16:52] <popey> sil2100, I am told that the rc proposed bq aquaris image is putting the old terminal (grey, with header) and old file manager (wrong icon) in the image, mhall119 just told me his recent flash did this
[16:53] <popey> sil2100, is there some thing you need to poke to make it pull the right ones in
[16:54] <davmor2> popey: what channel
[16:56] <sil2100> popey: yeah, so that's still untouched - the good news is that I have already created the job that would create the proper tarball, but didn't have the time to hook that up yet
[16:56] <sil2100> popey: (that's only for mako bq-aquaris.en)
[16:56] <popey> davmor2, not sure, getting this from mhall119
[16:56] <popey> ok, thanks sil2100
[16:56] <sil2100> davmor2: it's ubuntu-touch/rc-proposed/bq-aquaris.en
[16:56] <davmor2> mhall119: I assume is using the bq one for location then pretty sure that is the one he was using
[16:56] <sil2100> It's the old unmaintained channel that I wish to put life into and then migrate to a proper name
[16:57] <davmor2> sil2100: yeap just going for clarification
[17:06] <alex-abreu> robru, ping
[17:12] <mhall119> davmor2: yes, I used the rc-proposed/bq-aquaris.en channel for mako images
[17:12] <mhall119> other core apps might be old in that image too, but terminal and file manager were the ones I noticed
[17:13] <davmor2> mhall119: all of them are old :)
[17:14] <mhall119> davmor2: I can relate :)
[17:15] <davmor2> mhall119: meh you're not old, you have to get to my age to be old
[17:15] <mhall119> davmor2: I'm working on it
[17:16] <rvr> boiko: Approving silo 25
[17:51] <robru> morphis: except for the part where it created a second changelog entry with the same version repeated: https://ci-train.ubuntu.com/job/ubuntu-landing-054-1-build/lastSuccessfulBuild/artifact/bluez_vivid_packaging_changes.diff/*view*/
[18:02] <robru> Saviq: crap, yes
[18:10] <robru> Saviq: you around? just emailed you with a fix
[18:11] <morphis> robru: yes, is that something we can fix?
[18:12] <robru> morphis: hmmm
[18:13] <robru> morphis: try rebuilding with changelog "bluez (5.36-0ubuntu1) UNRELEASED; urgency=medium"
[18:14] <robru> morphis: I think when you say "vivid" in there the train thinks that's just an old entry and it tries to make a new one
[18:17] <morphis> robru: without bumping 0ubuntu1?
[18:18] <robru> morphis: well no you'll need to bump it now otherwise the ppa won't accept the upload
[18:18] <morphis> ok, as I thought
[18:22] <Saviq> robru, here
[18:23] <Saviq> robru, applying
[18:26] <Saviq> robru, just looking at that, is SILONAME an env var exported by the train? are there others we could rely on in debian/rules clean if we wanted to do some things there?
[18:27] <robru> Saviq: yes, the train sets that. there are a few others. if you run the build job with $DEBUG = true you'll see a nearly-full list
[18:27] <Saviq> robru, ok, /me will look into the .pot update in debian/rules clean
[18:28] <robru> Saviq: other than what you see with $DEBUG, train will also add $DIST='xenial' (or whatever series) just before the build.
[18:34] <bfiller_> popey: when get a chance there is a new camera-app in store ready for review
[18:40] <boiko> robru: hi, so there were some launchpad translations update on dialer and messaging on trunk, but QA has validated the silo already
[18:40] <boiko> robru: is it just a matter of rebuilding them and publishing?
[18:41] <popey> bfiller_, done
[18:42] <robru> boiko: I fixed the train so that it doesn't invalidate the silo over just translation updates, so you should be good to publish
[18:42] <boiko> robru: great! thanks!
[18:44] <robru> boiko: oh wait, just looking at this log, seems a bug. the publish job is blocking but the status says 'successfully built'
[18:44] <salem_> robru, I just published
[18:45] <salem_> robru, ah ok, it failed again
[18:45] <boiko> salem_: robru: yeah. same error
[18:45] <robru> boiko: salem_ sorry about that guys, will push a fix
[18:46] <boiko> robru: that's ok, just let us know when it is fixed
[18:48] <robru> fix is in trunk, will roll that out asap
[18:48] <dbarth_> hey robru, we've got a merge request for a new package; see https://requests.ci-train.ubuntu.com/#/ticket/695
[18:52] <robru> dbarth_: seems mostly reasonable but it looks like somebody copied an old example. standards version should be (i think) 3.9.6 and the vcs-bzr field can just be "lp:signon-plugin-sasl"
[18:54] <robru> boiko: ok try now
[18:54] <boiko> robru: thanks
[18:54] <robru> boiko: you're welcome!
[21:43] <bfiller> fginther: trying to build gallery in jenkins and having some problems: http://s-jenkins.ubuntu-ci:8080/view/click/job/gallery-app-click/304/
[21:43] <bfiller> fginther: any ideas what's going on?
[21:43] <fginther> bfiller, looking
[21:45] <fginther> bfiller, I don't see a problem. It claim "Successfully built package in './com.ubuntu.gallery_<IP_ADDRESS>0_armhf.click'." and I see the artifact was saved. What am I missing?
[21:46] <bfiller> fginther: seeing "Publishing status: Error during build publishing " with a stack trace, thought that was a problem
[21:47] <fginther> bfiller, ah. those messages are related to the sending of the results and artifacts to the external jenkins. We're investigating but it all appears to be working. https://jenkins.qa.ubuntu.com/job/gallery-app-click/304/ exists as expected
[21:47] <bfiller> fginther: ok cool, thakns
[21:47] <fginther> bfiller, sorry about that. For now it appears to be an annoyance, but not a real problem
[21:48] <bfiller> fginther: no worries


[08:45] <tumbleweed> Rhonda: from #ubuntu-devel: 08:20 < maxiaojun> http://packages.ubuntu.com should defaults to saucy now?
[08:56] <Rhonda> tumbleweed: hmmmm, indeed. I wonder why it doesn't, which file I forgot to deploy/change this time.
[08:58] <Rhonda> bleh, found it
[09:01] <Rhonda> Hmm, don't have the remote configured on my laptop.  *goeschecking*
[09:13] <Rhonda> tumbleweed: done
[09:14] <tumbleweed> Rhonda: thanks
[21:00] <jtaylor> nice libwx changed api/aabi with no transition :/
[21:03] <jtaylor> in debian too


 Is /usr/share/ a common location for program "factory" defaults, or is grub more of an exception?
[01:08] <Unit193> adrian_1908: A little of both really.  Usually /etc/default/* aren't also in /usr/share/, but I happen to know grub does do that, soo..
[01:08] <adrian_1908> I see, thanks for the quick help.
[01:13] <Unit193> Sure thing.
[01:14] <Unit193> Another cool feature, one can use drop-in snippets, such as /etc/default/grub.d/verbose.cfg
[02:05] <xubuntu74w> Hey, following this guide (http://ubuntuhandbook.org/index.php/2014/11/install-real-ubuntu-os-usb-drive/) I installed xUbuntu to a USB but whenever I go into my temp boot menu and boot from the Ubuntu option (with the USB drive inserted)  it shows something about a tpm chip and than goes into emergency mode. Can someone help?
[02:16] <adrian_1908> xubuntu74w: Maybe your system has restrictions set about booting from USB? You could check the BIOS for your settings.
[02:24] <xubuntu74w> adrian_1908 No in the past, I've been able to boot Linux lite off of a USB
[02:24] <xubuntu74w> Also, Secure boot is disabled
[02:30] <tomreyn> xubuntu74w: what is a "temp boot menu", how did you install to the usb storage?
[02:31] <tomreyn> it may also help to show the exact error message
[02:42] <xubuntu74w> tomreyn temp boot menu: Press enter on boot when prompted, press F12 and it takes me to a menu to select a device to boot from
[02:43] <xubuntu74w> I then choose ubuntu
[02:43] <tomreyn> oh you mean a boot menu provided by the mainboard firmware
[02:44] <xubuntu74w> Yeah
[02:46] <tomreyn> so it could be a broken installation, or something relating to the tpm or other hardware / firmware issue.
[02:47] <tomreyn> the exact error message may still help, or you could just verify the installer iso is complete and write it again, and verify that it was written properly.
[02:47] <xubuntu74w> that cant be right. If that was true than wouldn't windows not boot? and also in the past ive successfully installed and booted linux lite from usb
[02:49] <tomreyn> buggy firmware can cause some linux versions and distros not to boot fine when other OSs can boot. but so far my guess is rather with a broken installer.
[02:50] <xubuntu74w> So just reflash the live usb?
[02:51] <tomreyn> after verifying that the iso download is not corrupt, and before verifying the data written to the usb isn't
[02:51] <Bashing-om> xubuntu74w: As tomreyn surmisses; verify the write: https://help.ubuntu.com/community/Installation/CDIntegrityCheck
[02:53] <xubuntu74w> When flashing it, I used balinaetcher which  has a verify function. but I guess ill be right back.
[02:59] <xubuntu74w> Ok the media was checked and it said everything was fine
[05:43] <xubuntu66w> Hello, i have a question. I want add multi user system in OS. When user(not admin) install any software, admin will write sudo password from admin account.
[05:45] <xubuntu66w> User account also have password but it only for login in system
[21:54] <Noboru55> Hello everybody
[21:54] <Noboru55> I was playing supertuxkart, so i took a nap, and when i back i tried to open a pendrive, but nothing happened, so i decided to reboot the system
[21:54] <Noboru55> but, when reboot, i got screen (initramfs)
[21:55] <Noboru55> could do nothing, only a message saying something like a unxpected erro in my sda1
[21:55] <Noboru55> so i typed fsck /dev/sda1   and there i just did type Y  to all
[21:55] <Noboru55> now i am back to my Xubuntu
[21:55] <Noboru55> is there someway to see what happened ?
[21:56] <Noboru55> before the reboot i saw i could not open the partition sda2 (mybackup) too... the system was kind.. out.. not freezy
[21:57] <Noboru55> i do not know, logs.. or see if something could be broken after the fsck
[22:02] <Noboru55> brainwash the o.s got little broken, the chromium doesn't :D
[22:02] <Noboru55> still works very well, but a few seconds ago got a update
[22:05] <Noboru55> i guess the pendrive when mount maybe mess the sda1  do not know
[22:06] <Noboru55> ok, at least it is working...