[02:07] <nigel_nb> maco: ping
[02:39] <dtchen> nigel_nb: try back in an hourish (she's napping)
[02:39] <nigel_nb> dtchen: thank you :)
[02:39] <nigel_nb> good to know she's sleeping (for a change)
[04:00] <darkpixel> I have a simply python app that I am trying to package for both Hardy and Karmic.  According to the Debian guide the changelog supports something like 'mypackage (1.0) hardy karmic; urgency=log', but when I upload the source package to my PPA, it complains that I can only use one distribution at a time.  Is there an easy to use the same source for multiple releases?  Do I just need to create two identical copies of my ...
[04:00] <darkpixel> ... source just changing the changelog for each release?
[04:02] <ScottK> darkpixel: PPA specific questions are probably best asked in #launchpad.
[04:02] <darkpixel> ScottK: Will do.  Thanks.  I wasn't sure if this was me misunderstanding packaging or something specific to launchpad.
[06:07] <CarlFK> asac:  i see you do libgtk...   what does it take to get this included?  http://git.gnome.org/cgit/gtk+/diff/gdk/gdkwindow.c?h=gtk-2-18
[06:08] <CarlFK> I am building 2.18.3-1ubuntu2 now to make sure it builds clean, then again with that patch
[06:11] <slytherin> CarlFK: why is this change needed?
[06:12] <CarlFK> an app I use (dvswich) malfunctions
[06:12] <CarlFK> here is the bug report that lead to that fix:  https://bugzilla.gnome.org/show_bug.cgi?id=601473
[06:13] <slytherin> CarlFK: is there a bug in launchpad files against the app you are using?
[06:13] <CarlFK> no
[06:14] <CarlFK> should I ?
[06:14] <slytherin> yes
[06:15] <CarlFK> will do
[06:22] <CarlFK> slytherin:  Ill ref the debian and gnome reports - should I copy the text from the original debian bug report?
[06:23] <slytherin> CarlFK: Was that filed by you?
[06:23] <CarlFK> no - by ben, the lead dvswitch dev
[06:24] <CarlFK> but I am a dev, the one that found it, and care most about getting it fixed
[06:24] <slytherin> CarlFK: You can copy the description. Just mention that you copied form the debian bug (with url).
[06:27] <CarlFK> https://bugs.edge.launchpad.net/ubuntu/+source/dvswitch/+bug/491732
[06:41] <slytherin> CarlFK: I have changed the source package to gtk+. And since gtk+ is in main you may want to discuss the bug in #ubuntu-devel
[06:41] <CarlFK> oh right... dvswitch distracted me
[07:54] <dholbach> good morning
[08:07] <micahg> for an SRU using a bzr branch, so I still need to attach a debdiff?
[08:29] <micahg> jdstrand: bug 488559 didn't appear to make it into lucid yet, that version listed in teh bug didn't have it
[08:45] <akheron> geser: after discussing in #debian-mentors, too, I dropped the depends to libc6-dev | libc-dev: http://revu.ubuntuwire.com/p/jansson
[10:00] <iulian> Morning dholbach.
[10:01] <dholbach> hi iulian
[10:04] <^arky^> hi dholbach
[10:04] <dholbach> hey ^arky^
[10:04] <dholbach> how are you guys doing?
[10:06] <^arky^> great!
[10:10] <^arky^> any help on bug 491294 how to request a sync from debian ?
[10:11]  * iulian is not doing so good.
[10:11] <iulian> Headache is killing me.
[10:44]  * slytherin hates nick names with special characters
[11:28] <ciphergoth> hello masters of the Universe!  I maintain a package called mercurial-server that has very recently become part of Debian unstable.  I'd like to get this package into Lucid Lynx next.  What should I do?
[11:30] <geser> does it have any chance to move to testing?
[11:30] <ciphergoth> I just fixed the two low-priority bugs against it and pushed a 1.0
[11:30] <ciphergoth> I imagine it will end up in testing in the usual ten days
[11:30] <Laney> then it will get into Lucid automatically
[11:30] <ciphergoth> but I thought Ubuntu pulled from unstable?
[11:31] <ciphergoth> Laney: I haven't missed the cutoff date?
[11:31] <Laney> this release is syncing from squeeze by default
[11:31] <Laney> nope
[11:31] <ciphergoth> what is the cutoff date?
[11:31] <geser> not for lucid: for lucid we sync with testing
[11:31] <geser> once your package is in testing it should get auto-synced (don't know how often it get currently done)
[11:32] <geser> if it's not synced till DIF we can request a sync
[11:32] <geser> DIF= Debian Import Freeze
[11:33] <ciphergoth> and DIF is on December 31st?
[11:33] <Laney> !lucid
[11:33] <Laney> blast
[11:34] <Laney> https://wiki.ubuntu.com/LucidReleaseSchedule
[11:35] <ciphergoth> Laney:  that is the web page I have been looking for all over - thanks! I used the wrong search terms.
[11:35] <ciphergoth> https://wiki.ubuntu.com/LTSDebianImportFreeze is the key date it seems, and that's Feb 11th.
[11:36] <ciphergoth> that might even be time enough for me to Debianize my *other* package and get that one in too...
[11:37] <Laney> it's quite late this cycle
[11:37] <Laney> plenty of time
[11:37] <ciphergoth> yeah, I'd thought it would be much earlier.  Right, will do some hacking over the Xmas break :-)
[11:38] <ciphergoth> btw the one that's in Debian is http://www.lshift.net/mercurial-server.html and the other one is http://dev.lshift.net/paul/rurple/
[11:39] <ana_> yo guys! :)
[11:39] <ana_> i need help
[11:39] <ana_> my friends computer with UBUNTU 9.10 is freezing all the time
[11:39] <ana_> can somebody help me?
[11:39] <ana_> to solve this problem?
[11:39] <ciphergoth> ana_: you want the #ubuntu channel
[11:40] <ciphergoth> also, when you get there read the links in the "topic" for some hints on how best to get useful help
[11:40] <ana_> #ubuntu
[11:40] <ana_> hm:)
[11:41] <ana_> ok so i should go to ubuntu channel and than ask there
[11:41] <ana_> thank you ciphergoth
[11:42] <ciphergoth> You're welcome.  Remember to read the links in the topic.
[12:53] <Rune> Could someone please triage https://bugs.launchpad.net/ubuntu/+source/maxima/+bug/303587 its importance really is quite critical
[12:54] <Laney> Rune: we have the fixed version already
[12:54] <Laney> if #1 is to be believed
[12:56] <Rune> actually it reemerged
[12:57] <Rune> in karmic
[12:57] <Rune> see bottom comments
[12:57] <Laney> you should forward it upstream
[12:58] <Rune> some comments suggest it's a packaging problem
[13:05] <Laney> if it fails with ASLR, that sounds like an upstream bug
[13:16] <Rune> Laney, not a gcc problem as one of the comment suggest?
[13:16] <Laney> doubt it
[13:16] <Laney> but I don't know the problem obviously
[13:18] <Rune> It is hard for me to test because "apt-get source maxima; apt-get build-dep maxima; cd maxima-5.17.1; debian/rules;" does not work.
[13:18] <soren> It's not supposed to.
[13:18] <soren> Try "dpkg-buildpackage -rfakeroot -b" instead of debian/rules
[13:18] <Rune> ahh
[13:19] <Rune> thanks
[13:19] <soren> Rune: ^
[13:28] <Rune> I failed building maxima with dpkg-buildpackage. Then I tried rebuilding gcl with dpkg-buildpackage as gcl might be the sinner here. However, gcl did feel like compiling either because of ASLR.
[17:06] <stochastic> is there any way to "apt-get source" a Lucid package from within a Karmic install?
[17:12] <james_w> stochastic: you can add deb-src lines for lucid
[17:12] <james_w> stochastic: or there is pull-lp-source in ubuntu-dev-tools
[17:24] <Daviey> Do we have a DEP-3 comptiable equivilant to Bug-Debian: ?
[17:24] <Daviey> Or do we use that anyway to point to LP?
[17:24] <Daviey> (Ubuntu centric bug)
[17:49] <micahg> for an SRU on a package using a bzr branch, do I still need to attach a debdiff?
[18:05] <geser> probably as it's easier for the SRU people to review the changes you want to upload
[18:06] <micahg> geser: ok, thanks
[20:32] <WasserDragoon> hi, how to make a source package with 2 binaries?
[20:32] <WasserDragoon> using debuild
[21:03] <micahg> anyone available to push an SRU to proposeD?
[23:05] <awe_> nxvl, cody-somerville, could you one of you guys explain to me when how often merges.ubuntu.com refreshes?
[23:27] <ScottK> In theory every 6 hours.
[23:28] <ScottK> In practice, lately, not so much.
[23:33] <nxvl> awe_: ^^
[23:33] <nxvl> awe_: i always re-check with pts and lp to see if the versions are accurate
[23:34] <awe_> ScottK, thanks...
[23:35] <awe_> ScottK, the debian bzr branches for the package are out-of-date too ( james_w is looking at why ), so guess I'll have to do it the hard way.  ;)
[23:36] <james_w> awe_: if LP wasn't down I could force a check of the packages you want :-)
[23:36] <awe_> ;D
[23:38] <awe_> james_w, np, I managed to download my first source package directly from Debian, so progress is being made!
[23:38] <nxvl> awe_: what package are you working on?
[23:56] <micahg> anyone want to push an SRU into proposed?


[01:16] <frecel> has anyone else noticed that when you go to the ui designer in Qt Creator 3.4.0 (opensource) the whole IDE segfaults?
[01:53] <valorie> hi frecel
[01:53] <valorie> not sure how many here use qt creator
[01:54] <valorie> that said, alis tells me that there is #qt-creator chan
[01:55] <valorie> and "Bug tracking: http://bugreports.qt.io/"
[01:55] <frecel> valorie: thanks
[05:05] <ahoneybun> I'm getting real tired of these random Xorg issues or something
[05:07] <valorie> what issues are those, ahoneybun?
[05:07] <ahoneybun> sometimes I have just a black screen
[05:07] <ahoneybun> SDDM did not seem to start or something as I do not have options
[05:07] <ahoneybun> most likely from my Nivida driver
[05:08] <valorie> have you tried `systemctl enable sddm` in the cli?
[05:08] <valorie> that stopped that for me
[05:08] <ahoneybun> SDDM works sometimes
[05:08] <ahoneybun> not sure if it is SDDM at all
[05:09] <ahoneybun> pretty sure it is the NVIDIA driver
[05:10] <valorie> could be, I'm no expert
[05:10] <valorie> I had problems before doing that, and none after
[05:10]  * ahoneybun really needs his nonfree drivers for games
[05:11] <ahoneybun> thats one reason I say on Ubuntu
[05:11] <ahoneybun> of course SteamOS might be better for that lol
[07:03] <Etriaph> What kind of thin ice will I be in if I add next-stage2?
[07:06] <Etriaph> Ah, what the hell...
[07:06] <valorie> lol
[07:06] <valorie> living on the bleeding edge....
[10:38] <soee_> someone up ?
[10:54] <vip> naarp
[11:42] <BluesKaj> Howdy all
[11:52] <KDDA> hi BluesKaj
[11:53] <BluesKaj> Hi KDDA
[13:09] <soee> ok i added this: https://github.com/owncloud/client/issues/3273
[13:09] <soee> i think it is related to client not plasma itslef right ?
[13:20] <KDDA> what is the problem with it soee?
[13:20] <soee> KDDA: it is described there :)
[13:21] <KDDA> the owncloud settings window?
[13:21] <soee> yes, it shouldn't be loaded maximized when booting system
[13:22] <KDDA> is this the client or the server window?
[13:23] <soee> KDDA: client
[13:23] <soee> oh, Plasma 5.3.1 shoudl be released next week :)
[13:24] <KDDA> have you tried to build it manually in Kubuntu?
[13:25] <soee> nope :)
[13:26] <BluesKaj> hi soee,  will Plasma 5.3.1 be in the launchpad kubuntu-backports ppa ?
[13:27] <soee> BluesKaj: yes for 15.04, and in archve for Wily
[13:27] <soee> *archive
[13:28] <BluesKaj> Wily was listed in the launchpad ppa for 5.3
[13:29] <BluesKaj> oops sorry , it's not
[14:20] <yofel> "Ctrl-Alt-Del was pressed more than 7 times within 2s, rebooting immediately"
[14:20] <yofel> that's a thing o.O?
[14:26] <KDDA> where do you see that?
[14:26] <yofel> I had some I/O issues on my desktop, and when it got stuck during shutdown I pressed ctrl-alt-del repeatedly out of frustration, and got that ^^
[14:27] <yofel> I wonder if that's systemd
[14:27] <KDDA> very frustrated!
[14:27] <soee> :)
[14:28] <soee> do we have any pros fo far after switching to systemd ?
[14:30] <yofel> dunno, I have more issues than benefits at least. But as long as we iron those out before 16.04 it's fine
[14:31] <BluesKaj> yofel, had a kernel and some package upgrades yesterday on 15.04 and that solved my shutdown problem, for now.
[14:31] <KDDA> seems to have fixed mine too
[14:32] <yofel> hm, lets see what I have
[14:32] <KDDA> well shut down last night for me
[14:32] <BluesKaj> the same on 15.10
[14:32] <KDDA> yup
[14:33] <KDDA> system fully updated
[14:33] <yofel> hm, 47 updates, lets see
[15:27] <soee> nvidia driver 352 does not wor with 15.04
[15:27] <soee> :(
[15:27] <soee> seems like the only working driver is 346
[15:27] <soee> sad .. :(
[15:58] <BluesKaj> soee, using the 340 here without a problem...newer isn't always better
[16:31]  * ahoneybun confirms 346 works
[16:32] <ahoneybun> I see no 352 anyway
[16:36] <soee> ahoneybun: its beta version available through xorg edgers
[16:41] <ahoneybun> I see
[16:41] <ahoneybun> thanks for testing soee :)
[16:41] <ahoneybun> might need a patch to work with SDDM like 346 did
[16:52] <soee> why it does not work with sddm  >


 hi everyone 👋
 I'm here to ask if anyone could report that plasma or kde-applications on kubuntu are logging too much in journalctl
 I've seen it on Arch and Manjaro
[08:19] <utkojhamela> This happened to me once. The log file grown to several GB and filled the disc untill it is 0. Couldn't login via Desktop Interface because of itc I had to log in via tty, delete the log. But after login, it filled within few minutes again. I analyzed the log and seen which one is doing that, which one is entrying so much log. Found that, it was the Nvidia driver. I was using a Nvidia card, so installed the driver. Later the card got damaged, so I
[08:19] <utkojhamela> was using the onboard graphics. And the driver didnt find the card, so logging heavily. I uninstalled the nvidia driver, the problem was solved. Also noticed that, the + point: the standby cpu usage gone way down.
[08:26] <utkojhamela> IrcsomeBot: <mh_firouzjah>
 hi, each time i reboot my system I get this msg.
 https://irc-attachments.kde.org/e5afab0d/file_69293.jpg
 i have no idea what is the issue and i dont know how to fix it
 well, I'm currently using noveau and it has some "errors" in log and I know from before if I switch to Nvidia this will be gone but kernel starts warning about Nvidia module security (I've forgotten that special word it uses)
 so anyway having Nvidia means having some log reports
 but now my problem is on arch based distros plasma and other kde apps are filling logs too fast by any action (clicking or ...) or even without any user action (after logging in by placing the menu bar or so)
 I'm not taking about Arch Linux but the plasma has this problem
 *tip: to prevent such a situation you had before, there are some configuration to limit the size of journalctl logs saved on the disk (re @IrcsomeBot: <utkojhamela> was using the onboard graphics. And the driver didnt find the card, so logging heavily. I uninstalled the nvidia driver, the problem was solved. Also noticed that, the + point: the standby cpu usage gone way down.)
 maybe setting the "save for all users" option from the network control menu of system settings fix that (re @alibader84: i have no idea what is the issue and i dont know how to fix it)
[10:55] <user|58> hi
[10:58] <user|58> I have a problem
[10:58] <user|58> acpi error ae_not_found while resolving a named reference package element
[13:03] <jd_> f
[14:07] <pickanick> Keyboard shortcuts under the combination "Swap Ctrl and Caps Lock" option  + alternate layouts,  is buggy in: Kubuntu 22.04: KDE Plasma Version: 5.24.7 : KDE Frameworks Version: 5.92.0 : Qt Version: 5.15.3 : Kernel Version:5.15.0-86-generic (64-bit)  : Graphics Platform: X11
[14:07] <pickanick> Is this a known problem or where should I report it?
[14:50] <pickanick> .
[15:22] <BluesKaj> Hi all
 hi
 If I install gnome-disk-utility from the repositories, it installs the program in English, I would like to have it in my language, which is Spanish, can you tell me how I can do this?
[21:49] <user|88> Hello. I'm having issues with the latest 22.04 release and would like to download an older version instead. However, they don't seem to be available from kubuntu.org. Does anyone know where to find them? I'd prefer 22.04.1. Thanks.


[03:25] <greg_> hello
[03:54] <poningru> nixternal: ping
[04:16] <nixternal> poningru: pong?
[04:16] <poningru> nixternal: mailman is broken you cant send back email :( and hence cannot moderate like that
[04:18] <nixternal> ey?
[06:18] <beuno> jenda: moving ping
[06:20] <beuno> :D
[06:20] <beuno> first, everybody seems to point to you when it comes to trivia information
[06:20] <jenda> haha
[06:20] <beuno> UWN #32 still is missing that info  *wink *wink*
[06:20] <jenda> why would that be...
[06:21] <jenda> yeah, remove it.
[06:21] <jenda> :)
[06:21] <jenda> There haven't been any quizzes.
[06:21] <jenda> for about a month...
[06:21] <jenda> I can't get a hold of theCore
[06:21] <beuno> ok, gone
[06:22] <beuno> now, about DIY, I did have a talk with dan a few weeks ago
[06:22] <beuno> what's basically missing is very little programming on my side to get that up and running
[06:23] <boredandblogging> beuno, i'm new to the marketing team, trying to find a way to contribute, is there anything you need done for the UWN?
[06:23] <beuno> two things have prevented me from getting it done, first one is a LOT of work, which has left me with no strenght to keep on programming at home
[06:23] <beuno> and getting UWN back
[06:24] <beuno> boredandblogging: welcome, we sure can use some help!
[06:24] <boredandblogging> awesome, tell me what I can do
[06:24] <beuno> boredandblogging: something off the top of my head you can help with is the "In The Press" section, look for news articles on Ubuntu, and sum them up
[06:25] <beuno> I usually use news.google.com
[06:25] <beuno> but feel free to innovate
[06:25] <beuno> check out previuos UWNs to see how it has been done:  https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue31 and https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue30
[06:25] <adamant1988> You guys should really try "google alerts" for keeping up to date with Ubuntu
[06:26] <adamant1988> I get a daily condensed version of every new blog and news article with Ubuntu in the title
[06:26] <boredandblogging> yeah, thats a good idea, I'll set up some alerts for myself
[06:26] <adamant1988> or article
[06:26] <beuno> I'm currently trying to reduce the amount of information  been thrown at me, so it's not a good time, but it's a great idea
[06:27] <adamant1988> beuno: What kind of info is being thrown at you?
[06:27] <adamant1988> I'm fairly good with sorting incoming information into something that I can handle
[06:28] <beuno> adamant1988: mailing lists, rss, subscriptions, blogs...
[06:28] <adamant1988> beuno: You using gmail?
[06:28] <beuno> adamant1988: yeap
[06:28] <adamant1988> Ok, then managing all that info is easy, Gmail is freaking amazing
[06:28] <beuno> I've got it all organized, that's not the problem, the problem is I actually read through all of it
[06:28] <beuno> :D
[06:29] <adamant1988> Ah, well, I try to find the important bits and read those, haha
[06:29] <adamant1988> When it comes to RSS feeds
[06:29] <adamant1988> use BlogBridge
[06:29] <adamant1988> seriously
[06:29] <beuno> I use bloglines
[06:30] <adamant1988> No, blogbridge is the most full featured RSS-Reader I've ever seen
[06:30] <beuno> but still, I can't get it under 80 feeds I *want* to read
[06:30] <adamant1988> I've got tons of sorting options to get to the feeds I want quickly
[06:30] <boredandblogging> ok, so we don't edit the wiki directly, but use Gobby?
[06:30] <beuno> great, I'll give it a look
[06:30] <adamant1988> I'm only at 40, wow.
[06:30] <adamant1988> I edit the wiki directly...
[06:30] <beuno> boredandblogging: yes, usually we edit straight in the wiki
[06:30] <adamant1988> am I not supposed to?
[06:30] <boredandblogging> ok
[06:30] <beuno> just give me a few min, I'm edditing right now
[06:31] <beuno> dire up gedit meanwhile  :D
[06:31] <boredandblogging> thats fine
[06:31] <beuno> fire
[06:31] <boredandblogging> i think everyone guess through that cycle...subscribe to every imaginable feed, then realizes that they can't possible read them all
[06:31] <adamant1988> beuno: have you seen the spec I threw up last night?
[06:31] <adamant1988> boredandblogging: I manage my feeds very well thank you
[06:32] <boredandblogging> i think that JobBoard thing is interesting, would help out newbies like me...or just harass people in here
[06:32] <beuno> adamant1988: no, I have it flagged to look at, but it seems interesting
[06:32] <adamant1988> boredandblogging: well, it's not so much about helping you as making it easy for you to help out
[06:32] <beuno> UWN is suppose to go out tomorrow, so until then my attention is on there
[06:33] <adamant1988> beuno: Anything need done that I can handle?
[06:33] <adamant1988> although I disagree with the UWN's existence, I'll still help with it.
[06:34] <beuno> well, have you been following Feisty developments?
[06:34] <beuno> "Changes in Feisty" can use one or two more paragraphs
[06:35] <adamant1988> Admittedly I haven't kept up with it
[06:35] <adamant1988> I need to start subscribing to changelogs.
[06:36] <beuno> how about LoCo news?
[06:36] <adamant1988> Man, I'm so out of the loop
[06:37] <adamant1988> Ok, give me some feeds to subscribe to so I can keep up on this stuff for future reference.
[06:37] <beuno> haha
[06:37] <beuno> well, how about In the press?
[06:37] <adamant1988> I *do* have that.
[06:37] <beuno> help out boredandblogging
[06:37] <adamant1988> I get a google alert on that
[06:38] <adamant1988> We should add an "In the blogosphere" section :P
[06:38] <beuno> adamant1988: that's not a bad idea, we should run it by corey or jenda, but I like it
[06:39] <boredandblogging> I like it
[06:39] <adamant1988> beuno: I'll suggest that to the mailing list
[06:40] <beuno> adamant1988: great!
[06:41] <adamant1988> I've grown to like this mailing list thing
[06:42] <beuno> :p
[06:42] <adamant1988> Although I'm starting to wish I had a separate gmail account for all of them
[06:43] <adamant1988> But Gmail makes it easy to sort my info out, I'm just getting to a lot of labels
[06:43] <beuno> yeah, I've got a LOT of labels and filters
[06:44] <adamant1988> Shame :(
[06:49] <beuno> ok, adamant1988, boredandblogging, wiki is all yours
[06:49] <beuno> I'm going to take a shower
[06:49] <beuno> jenda: read up on what I said earlier on DIY, and we can talk about it  :D
[06:50] <jenda> oink
[06:50] <jenda> ok
[06:50] <jenda> I'm on my way out, though
[06:50] <beuno> jenda: np, we'll get back to that another time then
[06:51] <jenda> I see it. I also owe diy some content ;)
[07:13] <adamant1988> well, I changed my wiki again, lol.  I have a table of contents now lol
[07:16] <adamant1988> the mailing list seems dead today
[07:16] <adamant1988> something wrong with it?


[05:23] <Mirv> anpok: did you get what you needed to the 053?
[05:23] <Mirv> anpok: answer seems to be no, so copying. also, reconfiguring the silo the claim all of them are manual uploads, since it used to be dual landing for all and you want to continue doing dual landings (you can't now use the same MP:s for the vivid landing)
[05:24] <Mirv> anpok: or hmm, maybe that current line in there is good enough, but it was not reconfigured after the line was changed
[05:50] <Mirv> michi: hey! you could test on wily too, silo 021 has the same accessibility fix for wily. I think it'd be nice to see how it behaves in the exact thumbnailer scenario.
[05:50] <michi> Mirv: OK, I’ll have a look.
[05:50] <michi> Unfortunately, I don’t know how to install the new thumbnailer from a Jenkins build.
[05:51] <michi> Jenkins devel-ci still builds with the old version number.
[05:51] <michi> I’ll talk to James about it later today.
[05:53] <Mirv> michi: so the build from the silo 10 workarounds the issue ie is not good for testing it? can you give me the jenkins url? I believe if you can download the .deb:s from there and push them to device, you can dpkg -i *.deb them
[05:54] <Mirv> michi: I'm not otherwise in a hurry, but I'll be away for two weeks after today so if you want it in, I'd rather do it sooner than later today ;)
[05:54] <Mirv> I've already autopilot tested the vivid silo to have no regressions otherwise
[05:54] <michi> Mirv: No, I added our own work-around for the time being.
[05:54] <michi> To test whether it’ll work with the new network access manager, I need to build a new thumbnailer with the work-around removed and some extra trace.
[05:55] <Mirv> michi: ok
[05:55] <michi> But I can’t get the package that Jenkins builds for Arm onto the device right now because of the version going backwards.
[05:55] <Mirv> michi: dpkg -i forces even a downgrade
[05:56] <michi> Cool, I’ll try that, thanks!
[05:56] <Mirv> just adb push each .deb to the /home/phablet , then adb shell and dpkg -i *.deb
[05:58] <Mirv> you're welcome
[06:30] <anpok> Mirv: yeah I wasnt sure yesterday then ended my day..
[06:30] <anpok> Mirv: because of gtk+3.0
[06:31] <anpok> we are on 3.14 on vivd, and 3.16 on wily, I wasnt sure how to configure sync for all the others, but manual upload for gtk+3.14
[06:44] <Mirv> anpok: I'm actually not 100% sure either how it should be done :) but it's now all "manual" uploads, and the watch_only build is running so hopefully it should soon be ready to test
[07:08] <tsdgeos> Mirv: nice :)
[07:33] <Mirv> tsdgeos: you're welcome :)
[07:34] <Mirv> anpok: ah, 053 would need qtmir-gles and qtubuntu-gles still..
[07:34] <Mirv> anpok: I can handle those too
[07:35] <Mirv> anpok: or, hmm, they are outdated in 053, should they be the same version as wily has in 004? they don't seem to have vivid specific branches?
[07:36] <Mirv> anpok: correction, qtubuntu is up-to-date, qtmir in 004 only has your comment change so it does not matter
[07:38] <Mirv> anpok: -gles packages building for vivid now, watch https://ci-train.ubuntu.com/job/ubuntu-landing-053-1-build/11/console
[07:39] <seb128> hum
[07:41] <seb128> did people notice that the mir update is blocked in wily-proposed due to boottest regressions?
[07:41] <seb128> https://jenkins.qa.ubuntu.com/job/wily-boottest-mir/lastBuild/console
[07:41] <seb128> the logs don't have much details
[07:44] <Mirv> I'm not sure if the boottest is deemed to be trustworthy nowadays or not, but I can rerun it now to see if it persists
[07:45] <seb128> yeah
[07:46] <seb128> the thing is that it failed for all the packages in the set
[07:46] <seb128> e.g
[07:46] <seb128> https://jenkins.qa.ubuntu.com/job/wily-boottest-qtmir/lastBuild/console
[07:46] <seb128> that one has a "ERROR: timed out waiting for Unity greeter"
[07:47] <Mirv> anpok: ^ you should probably be interested in that wily mir problem, whether there's a real problem
[07:47] <Mirv> anpok: you could probably update to wily-proposed on device to see
[07:51] <jibel> seb128, actually there are lot of boottest failures http://paste.ubuntu.com/11891679/ is anyone looking at the results?
[07:52] <jibel> for exmaple lxc-android-config should be whitelisted, it cannot be installed directly
[07:53] <jibel> seb128, and when tests fail the log are not useful to do any diagnostics, eg. ubunut-system-settings-online-account ... Killed without further info
[07:54] <jibel> like mir
[07:57] <seb128> jibel, yeah, that's what I said "it failed for all the packages in the set"
[07:58] <seb128> that "lot" is just the new mir landing
[08:02] <anpok> Mirv: will have a look
[08:24] <jibel> Mirv, I re-ran all non-mir or qt boottest failures ie. pay-service platform-api thumbnailer trust-store ubuntu-app-launch ubuntu-system-settings-online-accounts
[08:24] <jibel> Mirv, lxc-android-config must be whitelisted, it  must be installed from recovery
[08:25] <jibel> Mirv, and the thumbnailer seems to be a real dependency issue in Wily
[08:25] <jibel> jamesh, ^
[08:28] <jamesh> jibel: what do you mean by "a real dependency"?
[08:28] <Mirv> jibel: ok
[08:28] <anpok> so the boot test fails because it attempts to upgrade lxc?
[08:28] <jamesh> real dependency issue.  Sorry
[08:29] <jamesh> if this is libleveldb1, won't that be fixed when the next image gets rolled?
[08:29] <anpok> jibel: btw pay-service ubuntu-app-launch ubuntu-system-settings-online-accounts are all part of the mir update.
[08:29] <jibel> jamesh, in the log of https://jenkins.qa.ubuntu.com/job/wily-boottest-thumbnailer/lastBuild/ there is this error at the end
[08:29] <jibel> The following packages have unmet dependencies:
[08:29] <jibel>  thumbnailer-service : Conflicts: libthumbnailer0 but 1.3+15.04.20150312-0ubuntu1 is to be installed
[08:29] <jibel> anpok, ok
[08:30] <jamesh> jibel: we shouldn't have any libthumbnailer0 now.  That package was removed
[08:31] <anpok> Mirv: just read the logs above.. thanks for cleaning up my mess.
[08:31] <Mirv> anpok: yes, the 053 seems to be intact for testing now. you're welcome.
[08:31] <jamesh> jibel: I believe the conflicts/replaces headers are correct (I applied the fixes infinity gave me)
[08:31] <Mirv> oh, I noticed only now that sil2100 had cancelled the hangou
[08:31] <Mirv> t
[08:31] <anpok> is there a way to manually upgrade without touching lxc-android-config?
[08:32] <sil2100> Mirv: yeah, not much to discuss
[08:32] <Mirv> anpok: what I do usually is just to dist-upgrade, then when it fails run sudo dpkg --configure -a
[08:36] <ogra_> hmpf
[08:37] <ogra_> none of the buttons in my indicators work on arale ...
[08:37] <ogra_> (i.e. tapping on battery settings in the indicator doesnt open anything)
[08:37] <ogra_> is anyone else seeing that ?
[08:38]  * ogra_ is on r52 on rc-proposed
[08:38] <ogra_> err
[08:38] <ogra_> r62
[08:38] <ogra_> updated 1h ago
[08:38] <jibel> ogra_, it works on r62
[08:38] <ogra_> hmpf
[08:39] <ogra_> i wonder whats wrong with my device then
[08:39] <jibel> they all work
[08:40] <anpok> Mirv: so it boots here after dist-upgrading.. so this was really just thumbnailer and lxc?
[08:41]  * ogra_ reboots, my spread also only shows shadows instead of app screenshots again
[08:45] <jamesh> jibel: I'm still not sure what that build log is trying to do.
[08:45] <Mirv> anpok: well if you're dist-upgrading after flashing today morning's image, there's only so much new there is
[08:46] <jibel> Mirv, can you help on the thumbnailer boottest failure, I am not sure either how boottest installs packages.
[08:49] <jibel> cihelp ^
[08:49] <psivaa> jibel: let me take a look
[08:58] <ogra_> sil2100, seems i386 failed to build for the last vivid image build
[09:07]  * sil2100 checks the logs
[09:09] <sil2100> hm, dep issues, unity8 couldn't be installed
[09:19] <Mirv> jibel: I don't find anything that would depend on the libthumbnailer0 with the new packages
[09:23] <Mirv> but maybe psivaa can find something more out
[09:23] <psivaa> still digging, all devices being occupied does not help speed up :)
[09:30] <jibel> ogra_, how do you reproduce the "shadow effect"? I never saw it
[09:30] <ogra_> jibel, i simply use the device
[09:31] <ogra_> it starts happening after a few hours ... and gets worse over time
[09:31] <jibel> ogra_, me too :) any specific use of the device?
[09:31] <jibel> hm
[09:32] <ogra_> jibel, no, i have my usual 5 apps open, nothing fancy
[09:32] <ogra_> seems it is worse if the browser is open alongside
[09:44] <sil2100> Oh
[10:01] <psivaa> jibel: Mirv: i don't think we could make libthumbnailer0 work with boottest as it's currently setup,
[10:02] <psivaa> this is due to the fact that its  ubuntu-touch/devel-proposed/krillin.en vivid being the base image where the boottests are run
[10:03] <psivaa> and the fact that we're trying to install wily version of thumbnailer-service as part of the testrun, which conflicts with libthumbnailer0
[10:03] <psivaa> http://paste.ubuntu.com/11892053/
[10:04] <psivaa> So, thumbnailer(wily) -> installs thumbnailer-service(wily) on vivid base which already has thumbnailer0, which is conflicting
[10:05] <psivaa> s/thubnailer0/libthumbnailer0
[10:07] <jamesh> psivaa: thumbnailer-service should be replacing everything we had in libthumbnailer0, and there are no further dependencies
[10:07] <jamesh> further dependencies on that package
[10:11] <sil2100> Mirv: interesting... I'm looking into the reason why our last i386 image didn't build correctly
[10:11] <jamesh> psivaa: if the test is actively trying to install libthumbnailer0, then that sounds like a problem with the test.
[10:13] <sil2100> Mirv: and this might also be related to the thumbnailer landing, but hm, the error is a bit strange
[10:14] <sil2100> Mirv: the shlibs:Depends on thumbnailer generated something really strange
[10:15] <sil2100> Mirv: qtdeclarative5-ubuntu-thumbnailer0.1 has such a dep currently: libqt5quick5 (>= 5.4.1-1ubuntu7) | libqt5quick5-gles (>= 5.4.1-1ubuntu7) <- first, not sure why shlibs is suddenly depping on the exact version number, and why did it mark requiring 5.4.1-1ubuntu7 for -gles if gles is currently one rev behind (5.4.1-1ubuntu6)
[10:18] <sil2100> 5.4.1-1ubuntu7 does not and never existed for the -gles version
[10:25] <Mirv> sil2100: eh..
[10:26] <Mirv> sil2100: is the i386 image an emulator image? that could mean that we should not allow the versions to go out of sync, since the .symbols file might declare the dependency like that
[10:26] <sil2100> Ah... right, yeah
[10:26] <Mirv> sil2100: oh, oh... this is the first time ever this is happening, and the reason is that in ubuntu7 we added backported feature from Qt 5.6 which the new thumbnailer is using
[10:26] <sil2100> I thought we generally avioided depping on particular -0ubuntu versions
[10:27] <Mirv> sil2100: this is packaging automagically doing the correct thing... well, almost, the gles should not be like that
[10:27] <sil2100> Ok, that explains it
[10:27] <Mirv> sil2100: so I think we need to do no-op gles build bumping the version nuumber
[10:27] <Mirv> sil2100: siloing
[10:27] <sil2100> Mirv: yes, certainly
[10:27] <sil2100> Thanks :)
[10:27] <sil2100> Generally I hate depping on ubuntu versions, but in the case of Qt well... I guess there's nothing better one can do
[10:30] <cwayne> sil2100: heya
[10:30] <sil2100> cwayne: hey!
[10:30] <Mirv> sil2100: that's not happening in general - but here it is since ubuntu7 version specifically added new symbols that thumbnailer is now using
[10:31] <cwayne> sil2100: any idea whats going on with importing images? the last arale custom tar that was built still hasn't shown up in meizu.en-proposed
[10:31] <sil2100> cwayne: oh? Still? Let me check the config and the s-i server
[10:31] <sil2100> One moment
[10:32] <Mirv> sil2100: generally packages don't add new features in ubuntuX versions :)
[10:36] <sil2100> Mirv: yeah, that's what I expected and scratched my head about ;)
[10:37] <sil2100> But yeah, this is a special case
[10:45] <sil2100> hmmm
[10:45] <sil2100> Ah!
[10:45] <sil2100> I see a typo in the config
[10:45] <sil2100> cwayne: ^
[10:46] <cwayne> huh, how did it ever work then i wonder
[10:46] <sil2100> cwayne: not sure, it shouldn't have worked in the past, not for meizu.en-proposed
[10:48] <cwayne> lol
[10:49] <sil2100> Strange that the jenkins job urls are different there
[10:49] <sil2100> cwayne: anyway fixed now
[10:49] <sil2100> Let's wait for another importer run
[10:54] <Mirv> sil2100: ^ 008 built, is it possible to test it with the image similar to how you debugged it
[10:55] <sil2100> Mirv: I can try, I debugged it on my chroot, still have it open
[10:55] <sil2100> I'll just add your PPA to sources
[10:55] <Mirv> sil2100: hmm, the publisher didn't yet run though. build finished 6 minutes ago so 4-9 to go.
[10:55] <Mirv> sil2100: thanks
[10:56] <sil2100> Ok, I'll prepare everything in the meantime
[10:58] <Mirv> sil2100: ok now it should be done
[11:03] <sil2100> uh
[11:03] <sil2100> Mirv: still a problem
[11:03] <sil2100> Mirv: it needs to be 5.4.1-1ubuntu7 not 5.4.1-0ubuntu7
[11:04] <sil2100> It looks like the non-gles version was a debian -1, so the -gles one needs  that too
[11:04] <sil2100> So, not -0ubuntu7 but -1ubuntu7 (didn't notice that originally)
[11:08] <psivaa> jamesh: The test does try to install libthumbnailer0, qtdeclarative5-ubuntu-thumbnailer0.1, thumbnailer-common and thumbnailer-service
[11:08] <psivaa> jamesh: this is because libthumbnailer0 is already an installed package due to the base image being vivid
[11:09] <psivaa> jamesh: please take a look at lines 155,162 and 163 in http://bazaar.launchpad.net/~canonical-ci-engineering/ubuntu-touch-boottest/trunk/view/head:/boottest.sh
[11:18] <sil2100> Mirv: regarding silo 006 - we need to make sure it's also released to wily
[11:20] <Mirv> sil2100: ouch... so I must lie about the package being in Debian while it isn't
[11:20] <sil2100> :<
[11:20] <Mirv> ok then
[11:23] <jamesh> psivaa: so that test has no chance of ever succeeding if we ever merge two binary packages (like we did for thumbnailer)
[11:24] <psivaa> jamesh: right, with this way we wont have thumbnailer passing :/
[11:37] <psivaa> Mirv: jibel: not sure if you noticed, the majority of the boottest failures (other than thumbnaier) are due to ''ERROR: timed out waiting for Unity greeter'
[11:38] <psivaa> one possible cause as pitti suspected could be the new Mir
[11:39] <Mirv> psivaa: I understood anpok tried testing it already (or well, at least he did test the silo that landed last night)
[11:40] <anpok> psivaa: I took todays devel-proposed image and upgrade to wily-proposed
[11:40] <anpok> *upgraded
[11:40] <anpok> boots fine
[11:42] <psivaa> anpok: is this the base image that you used, just to confirm, http://paste.ubuntu.com/11892361/
[11:43] <anpok> i used mako version 258
[11:44] <anpok> version_detail: ubuntu=20150717,device=20150708,custom=20150717,version=258
[11:47] <anpok> psivaa: ok comparing to boottest - I bootstrapped but then just I dist-upgraded
[11:47] <anpok> & updated..
[11:48] <sil2100> Mirv: testing!
[11:48] <Mirv> sil2100: ok, try again, silo is ready
[11:48] <Mirv> sil2100: heh
[11:48] <Mirv> good timing
[11:48] <karni> ping trainguards -- I wanted to make you aware that last thumbnailer changes have broken Telegram, and the app will not start in rc-proposed
[11:48] <karni> I've contacted #unity-api team
[11:48] <karni> We dynamically link with libthumbnailer.so, which seems to be gone from the system
[11:49] <Mirv> jamesh: ^
[11:49] <karni> http://paste.ubuntu.com/11892354/
[11:49] <sil2100> Mirv: works!
[11:49] <Mirv> sil2100: \o/
[11:49] <karni> yes, I've pinged jamesh about it
[11:49] <Mirv> sil2100: publishing
[11:49] <karni> waiting for his response
[11:50] <psivaa> anpok: ack, but i'd do a test on krillin to confirm, the fact that mako successfully booting does not confirm that it will boot with krillin
[11:50] <anpok> psivaa: yup switching devices now..
[11:51] <rvr> sil2100: Hi. In silo 7, dashboard says "caught signal 15, aborting". What does it mean?
[11:52] <greyback> rvr: it means I cancelled the build
[11:52] <rvr> greyback: So, is it ready for testing or not?
[11:52] <greyback> rvr: sadly no, I need to rebuild it and test it once mir in silo 4 lands
[11:53] <sil2100> greyback: uh, remember that cancelling a job before it finished preparing the packages is VERY risky
[11:53] <sil2100> By risky I mean in certain cases it can lead to the silo being broken
[11:53] <sil2100> Only abort when packages are prepared
[11:54] <rvr> greyback: Ok, removing the trello card
[11:54] <greyback> sil2100: it was a pretty quick cancel
[11:54] <greyback> *sigh* that has been sitting there for days
[11:55] <greyback> sil2100: but noted, I shall avoid doing so in future
[12:02] <seb128> hum
[12:02] <seb128> Mirv, jibel, so that mir update/boottest regression, I think it's real
[12:02] <seb128> I tried to install the new mir here on my n7 which is on wily
[12:03] <seb128> and it has the ubuntu log with 4 dots splash (new, looks nice!) but unity8 never shows and apport triggers on boot for unity8-dash
[12:05] <jibel> anpok, ^
[12:06] <anpok> yes seeing that.. do we have startup logs from unity8-dash/
[12:06] <jibel> seb128, good that boottest caught it. Thanks for the verification.
[12:06] <seb128> yw!
[12:06] <seb128> also the mir transition is incomplete
[12:07] <seb128>  url-dispatcher : Depends: libmirclient8 (>= 0.13.2+15.10.20150605) but it is not going to be installed
[12:08] <seb128> ubuntu-push-client as well
[12:09] <seb128> ciborium
[12:52] <kyrofa> trainguards: I just added another branch (same project) to my spreadsheet item. Do I need to do anything else to get that new branch into my silo?
[12:55] <Mirv> kyrofa: the silo needs to be reconfigured to include it
[12:56] <Mirv> kyrofa: since I'm not sure if you can do it, I just reconfigured it for you. now it should work/build fine.
[12:57] <anpok> seb128: there was an update to gtk-3.0 - in the mean time - do we have to upload a new source package to silo-004?
[12:57] <kyrofa> Okay, thanks Mirv!
[12:57] <seb128> anpok, no, the silo landed in wily-proposed it's not needed anymore, right?
[13:00] <anpok> seb128: ah ok so gtk+3.0 3.16.5.-1ubuntu2 was built again libmirclient9 and contains the deprecation free mir platform patches
[13:00] <anpok> +?
[13:01] <anpok> seb128: silo-004 now has url-dispatcher
[13:01] <seb128> anpok, updating the silo doesn't make sense since it landed to distro already, no?
[13:01] <seb128> anpok, and yes, the gtk upload was to fix an issue with the silo version
[13:04] <Mirv> seb128: the silo can be republished to fix proposed migrations, since it's only emptied if the migration succeeds
[13:04] <anpok> seb128: just thought we need a rebuilt url-dispatcher package to resolve the problem..
[13:04] <Mirv> but in this case one might to fix archives manually since the fixes are also manual uploads to the silo
[13:04] <seb128> Mirv, wouldn't it be more efficient to just upload the extra rebuild directly to the archive?
[13:04] <Mirv> seb128: yes, exactly
[13:05] <Mirv> but if they are built in the silo, one can also copy-package those to the archives
[13:05] <anpok> (and there is silo-053 which needs it too)
[13:30] <greyback> sil2100: heh you were right, I screwed up silo7 by cancelling a build. Do I need to clean & start again?
[13:31] <sil2100> greyback: might be the easiest way, if that's not a problem for you
[13:33] <greyback> sil2100: looks like nothing is easy https://ci-train.ubuntu.com/job/ubuntu-landing-007-3-merge-clean/42/console
[13:33] <sil2100> Yeah, that's normal... it's freed now, this is normal when the config file got erased/corrupted
[13:33] <sil2100> Re-assign and it should be good
[13:34] <greyback> sil2100: cool, ta
[13:48] <pmcgowan> can silo 2 be marked as passed
[13:48] <kyrofa> trainguards: dh-exec .install files aren't getting multiarch variables in my silo, but it works in my local pbuilder. What's wrong?
[13:48] <sil2100> pmcgowan: did QA sign it off?
[13:48] <pmcgowan> they did
[13:48] <pmcgowan> acc to trello yesterday
[13:49] <sil2100> hm, someone forgot to switch it then
[13:49] <sil2100> jibel, davmor2: setting the silo as passed
[13:59] <cwayne> sil2100: anyone in qa available to help test the latest arale custom + silo 35?
[13:59] <cwayne> i broke my arale at the worst possible time :(
[14:00] <sil2100> jibel, davmor2: ^ do you have anyone that could help? ^
[14:02] <davmor2> jibel: I can take it
[14:03] <davmor2> jibel: that way cwayne only owes one person drinks for the rest of their lives ;)
[14:03] <cwayne> :)
[14:05] <cwayne> davmor2: so, the steps to test: 1) install rc rev 2 on arale
[14:05] <cwayne> 2) favorite/unfavorite some scopes
[14:05] <cwayne> 3) switch channel to ubuntu-touch/rc-proposed/meizu.en-proposed
[14:05] <cwayne> 4) install ubuntu-touch-customization-hooks from silo 35
[14:06] <davmor2> cwayne: sure on it
[14:06] <cwayne> davmor2: <3
[14:07] <davmor2> cwayne: that's fine I never have to buy a drink again eva ;)
[14:07] <cwayne> davmor2: that is correct
[14:07] <cwayne> although penk will owe those to me since this isn't my tarball anymore :P
[14:08] <davmor2> cwayne: who requested the testing, Didn't see penk nick there once :P
[14:08] <cwayne> davmor2: lol
[14:10] <pmcgowan> sil2100, silo 6 can publish
[14:10] <sil2100> pmcgowan: I know, need to discuss that first
[14:10] <sil2100> pmcgowan: it's a direct upload to vivid, need to make sure those changes are staged for wily too
[14:10] <sil2100> It was a request from slangasek and awe_ mentioned he can start doing that post-OTA-5
[14:11] <pmcgowan> sil2100, ok
[14:11] <sil2100> Will publish once I have the situation cleared out
[14:12] <awe_> sil2100, I don't really see the context in the scrollback?
[14:13] <pmcgowan> awe_, silo 6 is network manager change
[14:14] <pmcgowan> but its vivid only?
[14:14] <sil2100> awe_: you weren't around when it got ready for publish - waiting for Steve's comment on if I can simply push it normally to vivid
[14:14] <awe_> because (a) we forked NM due to the desktop routing change which I didn't want to accept
[14:15] <sil2100> Since there's no silo/request with the same change in wily
[14:15] <awe_> and (b) I focused on getting everything landed for the phone first
[14:15] <awe_> pmcgowan, sil2100 and I discussed this.  I'm currently working on landing all of the changes in wily now
[14:15] <awe_> as separate landings
[14:15]  * awe_ is editing .patch files as we speak
[14:16] <sil2100> awe_: ok, so you want this to still go in and then you'll land it with all the others for wily, right?
[14:16] <awe_> yes
[14:16] <awe_> but go into the overlay PPA
[14:16] <awe_> not vivid itself
[14:16] <awe_> did I get the citrain fields wrong?
[14:17] <sil2100> awe_: I suppose it's fine, remember our kind request to at least get the silo for wily with each vivid-overlay landing once you sync it up
[14:17] <sil2100> The release team doesn't like when we land things in overlay first, it introduces the risk of the delta between devel and stable
[14:18] <awe_> sil2100, I don't like shipping phones with unstable code
[14:18] <awe_> I put my efforts on supporting devices we'd shipped, and explained myself in depth
[14:19] <awe_> this should have zero impact on desktop
[14:20] <sil2100> Right, and we're thankful for that, but we need to make sure that everything that lands to the stable devices also lands to the devel ones
[14:21] <sil2100> Otherwise, once we finally switch sometime in the future to the new series, we don't miss any fixes - and this already happened the last time for multiple projects
[14:21] <sil2100> So the release team is really cautious here
[14:25] <kyrofa> trainguards: I'm having some trouble in silo 11. My dh-exec .install files aren't getting $DEB_HOST_MULTIARCH defined... and I'm not sure why. It works locally
[14:26] <sil2100> awe_: did cyphermox take a look at those changes? Asking since this would mean it's already been reviewed from the packaging POV
[14:26] <sil2100> kyrofa: hm, let me take a look if it's something we can help with
[14:27] <kyrofa> sil2100, thanks. I can do it in override_dh_auto_install, but the debian wiki suggested dh-exec (https://wiki.debian.org/Multiarch/Implementation#Dynamic_debian.2F.2A_files)
[14:28] <awe_> sil2100, it was approved by abeato_ only
[14:30] <awe_> sil2100, as for the packaging, as NM is a packaging only branch, that's all I modified.  I added a new patch, and corresponding changelog entries
[14:30] <sil2100> awe_: yeah, thinking how to proceed with that, last time I just published it as it's nothing more than like publishing a code-only-change, but...
[14:30] <sil2100> Our agreement with the release team is strange
[14:31] <sil2100> Ok, I'll take it on me then
[14:32] <awe_> sil2100, what should I have done differently?
[14:32] <sil2100> awe_: everything fine from your side, although I would prefer cyphermox to be aware of the changes, it was more of if I should find a core-dev to approve it first or not...
[14:32] <awe_> if I always get a core-dev to review, would that smooth this out next time?  That seems odd, given that I'm landing in the overlay PPA, but if that's the requirement, so be it
[14:57] <davmor2> cwayne: should that of fixed the issues with only seeing 6 icons if so fail, Does it need to be installed during the install of the upgrade?
[14:58] <cwayne_> oh shit i think i forgot to rebuild the package with scott's latest fix
[15:00] <cwayne_> sorry davmor2, ill ping you once i get it rebuilt
[15:15] <kyrofa> sil2100, have you had a change to take a look at the dh-exec stuff in silo 11 yet?
[15:16] <sil2100> kyrofa: looking, but in a meeting still so it's hard to concentrate
[15:17] <sil2100> But I see what you mean
[15:17] <kyrofa> sil2100, heh, no problem :)
[15:18] <kyrofa> sil2100, it's not some sort of security thing, is it? Since the .install files are executable?
[15:30] <kgunn> robru: so, anpok (who's missing from irc atm) updated silo4 due to getting stuck in proposed....has now seemed to correct the silo, can you attempt to pub again?
[15:30] <kgunn> camako: ^
[15:31] <rvr> mzanetti: ping
[15:35] <mzanetti> hi victor
[15:35] <mzanetti> rvr, ^
[15:36] <rvr> mzanetti: Hey
[15:36] <rvr> mzanetti: I'm testing silo 48
[15:36] <rvr> mzanetti: I have a problem with the "start" gesture/Launcher button
[15:37] <mzanetti> hmm
[15:37] <mzanetti> what issue=
[15:37] <mzanetti> ?
[15:37] <rvr> mzanetti: Without the silo, when I'm on the news scope, pressing the "start" makes the Dash go back to the first scope
[15:37] <rvr> e.g. Today
[15:37] <rvr> mzanetti: With the silo, doesn't do anything
[15:38] <mzanetti> I did think there's something weird when I tested it... but tsdgeos convinced me it was good as it is :)
[15:38] <mzanetti> let me verify
[15:38] <tsdgeos> rvr: mzanetti: ok that's bad and should not have regressed
[15:38] <mzanetti> indeed
[15:39] <mzanetti> it seems to behave differently
[15:39] <mzanetti> yeah... bug... I guess that means failing the silo :/
[15:39] <rvr> Yup
[15:39] <tsdgeos> meh :/
[15:39] <mzanetti> sorry rvr
[15:39] <tsdgeos> throw away that branch
[15:39] <tsdgeos> and create unittest
[15:40] <popey> karni: is there a bug for broken telegram / thumbnailer wencan point people to?
[15:40] <karni> yes, 1 sec
[15:41] <karni> popey: https://bugs.launchpad.net/libqtelegram/+bug/1475691
[15:41] <mzanetti> rvr, I'll drop that branch from the silo and rebuild the rest as it is, ok?
[15:41] <rvr> mzanetti: Ok
[15:44] <popey> karni: thanks
[15:51] <davmor2> cwayne: relocating to the caravan back in 40 minutes-ish
[15:54] <cwayne_> davmor2, ack
[16:07] <sil2100> kyrofa: hm, I wouldn't do it in this way for sure
[16:09] <kyrofa> sil2100, how come?
[16:13] <sil2100> One moment
[16:17] <sil2100> kyrofa: so generally the recommended way is to make the build system take care of building/installing the binaries in the right multiarch directory and then just ask packaging to install them to their respective ones in the system
[16:19] <kyrofa> sil2100, dh-golang doesn't do that. The go idioms have no way to do that. I have to do it by hand, one way or another
[16:19] <sil2100> kyrofa: ouch, ok, this changes the situation - ok, we can do it differently
[16:20] <sil2100> Sadly I'm a bit overloaded with work right now
[16:20] <kyrofa> sil2100, I can add a Makefile rule to copy binaries around, but that's really the same thing
[16:20] <sil2100> Could you try poking some core-devs for advice here?
[16:20] <cwayne_> davmor2, so package should be ready whenever youre back
[16:20] <kyrofa> sil2100, I'd be happy to-- any recommendations?
[16:22] <sil2100> kyrofa: I would say poking slangasek, ogra_, seb128 or infinity - not sure which one of them would have some free cycles :)
[16:22] <kyrofa> sil2100, alright, thanks!
[16:32] <slangasek> sil2100, kyrofa: I would not expect there to be any multiarch directories that are relevant to golang.  this is silo 11?
[16:33]  * sil2100 has no experience with golang
[16:33] <kyrofa> slangasek, indeed it is. I'm just trying to place a unity scope in the right multiarch place
[16:34] <kyrofa> slangasek, but the go tools don't support installing anywhere other than $GOPATH/bin, and dh-golang straight-up copies binaries to /usr/bin, so I wrote .install files to move them to the right spot
[16:36] <slangasek> kyrofa: what's the right multiarch place, in this context?
[16:37] <kyrofa> slangasek, /usr/lib/${DEB_HOST_MULTIARCH}/unity-scopes
[16:37] <slangasek> ok
[16:38] <slangasek> so I think it's fine to use dh-exec for this, and move the file from /usr/bin to /usr/lib/${DEB_HOST_MULTIARCH}/unity-scopes in the .install
[16:38] <kyrofa> slangasek, it works fine on my local pbuilder, but in the silo it creates a directory named literally "${DEB_HOST_MULTIARCH}"
[16:39] <slangasek> ah
[16:39] <slangasek> kyrofa: is the executable bit of the .install file represented in your branch?
[16:39] <slangasek> or is this a source upload?
[16:41] <kyrofa> slangasek, indeed it is represented
[16:41] <kyrofa> slangasek, I was wondering if it was some kind of protection in the silo that disallowed execution
[16:42] <slangasek> not "protection", just "bug"
[16:42] <kyrofa> slangasek, if you're curious: lp:~kyrofa/unity-scope-snappy/improve_debs
[16:42] <kyrofa> slangasek, heh :)
[16:43] <kyrofa> slangasek, so I can obviously do this in debian/rules, just not nearly as slickly
[16:43] <slangasek> kyrofa: actually, the problem is that the package doesn't declare itself to be source format 3.0
[16:43] <slangasek> so there's no way to represent this executable bit on a round trip into a .dsc and back
[16:44] <kyrofa> slangasek, hmm. I was specifically asked to remove that :P
[16:44] <slangasek> by whom? :)
[16:45] <slangasek> kyrofa: you'll want to create debian/source/format with contents '3.0 (quilt)', build a source package, unpack it again, and test the build - that should let you verify that the source package is being generated correctly
[16:46] <kyrofa> slangasek, robru asked me to drop debian/source entirely
[16:47] <slangasek> kyrofa: ok; robru is mistaken on this :)
[16:47] <kyrofa> slangasek, okay, initially I had 3.0 (native) with a version number of 0.1.0 (no -0ubuntu1). I should do quilt instead?
[16:48] <slangasek> kyrofa: ah - yes, 3.0 (native) is wrong because this isn't a native package (native == no separate upstream and Ubuntu parts)
[16:48] <slangasek> kyrofa: 3.0 (quilt) is the right thing here
[16:49] <kyrofa> slangasek, alright. I'm a bit confused by that though. This is a Canonical project, for Ubuntu Personal. Can you explain how the upstream and Ubuntu parts are separate in this case?
[16:50] <slangasek> no but I can handwave furiously
[16:50] <kyrofa> slangasek, (I'm not a packaging pro, as you may have gathered :)
[16:51] <slangasek> kyrofa: the fact is, we use non-native version numbers for all of these packages, and the train autogenerates the upstream tarballs; so they're non-native packages in that sense, and also in the sense that any Ubuntu developer can upload a -0ubuntu2 revision to the archive using the same tarball
[16:51] <kyrofa> slangasek, ohhhh
[16:51] <kyrofa> slangasek, okay, I've gotcha :)
[16:51] <slangasek> so we just want to be consistent with that, even if the distinction between native and non-native is somewhat arbitrary
[16:52] <kyrofa> slangasek, fixing now!
[16:52] <kyrofa> slangasek, thank you very much
[16:53] <slangasek> kyrofa: no prob
[17:00] <kyrofa> slangasek, in order to test that out locally then, I'll need to create an upstream tarball?
[17:01] <slangasek> kyrofa: you should be able to download the existing one from the ppa
[17:01] <slangasek> (in order to not have to reproduce the train's own tarball synthesis)
[17:03] <dobey> hmm
[17:03] <dobey> kyrofa: if you use 3.0 (native) you don't need an upstream tarball
[17:04] <dobey> slangasek: my recommendation here is to use 3.0 (native) and a proper native version string in debian/changelog
[17:05] <dobey> slangasek: it is a native package, because there are no separate upstream and ubuntu parts
[17:05] <slangasek> dobey: that is an option, but I don't like native packages in general and I'm not sure how the train would handle that
[17:05] <slangasek> there certainly are
[17:05] <robru> slangasek: what? we have guidelines on this we've been using for a couple years now: https://wiki.ubuntu.com/DailyRelease/InlinePackaging (this is even since pre-train days)
[17:05] <dobey> what is the separate ubuntu part?
[17:05] <dobey> robru: those guidelines are ill-informed
[17:06] <slangasek> dobey: the debian/ directory is maintained by the Ubuntu developers, not by upstream
[17:06] <dobey> slangasek: it is maintained in the upstream source tree
[17:06] <slangasek> sometimes
[17:06] <dobey> in this specific case
[17:07] <dobey> (for most things landing via ci train, even)
[17:07] <slangasek> the packaging changes are owned by the Ubuntu developers, not by the upstream developers (thus Ubuntu dev sign-off is required for any changes); and sometimes Ubuntu changes land in the archive without being landed in the upstream trunk
[17:07] <slangasek> so no, not native
[17:07] <dobey> then someone needs to fix dpkg to support something that isn't native, but which isn't ubuntu either. because these things are somewhere in the middle, by that argument
[17:07] <slangasek> robru: well, inasmuch as those guidelines are incompatible with dh-exec, the guidelines are wrong.  Is there a reason that 3.0 (quilt) would be unsupported by the train?
[17:07] <robru> dobye: slangasek: train explicitely requires debian/ in the upstream trunk, we don't support anything else
[17:08] <slangasek> dobey: nope, this is non-native.
[17:08] <dobey> the upstream source tree is the canonical debian/ directory.
[17:08] <dobey> therefore it is native
[17:08] <slangasek> no, it's not
[17:08] <slangasek> it's not canonical, and it's not native
[17:08] <dobey> any changes uploaded directly to the archive, outside of that, would be non-native
[17:08] <slangasek> the canonical debian/ directory is whatever goes into the archive
[17:08] <robru> slangasek: the idea is that the train only works on canonical-owned projects so there just shouldn't be any quilt patches at all.. they should all be upstreamed
[17:08] <slangasek> yeah, we don't flip-flop packages between native and non-native on each upload
[17:08] <slangasek> robru: I'm not talking about quilt patches here
[17:09] <slangasek> that's the format name; it's not required that there be any quilt patches in the debian directory
[17:09] <dobey> it is native, but whatever
[17:11] <robru> slangasek: IIRC dobey hacked in support for native packages, but the version-generating feature doesn't work as well. definitely non-native is the way to go to be a first class citizen in train land.
[17:12] <dobey> yes, native packages work in the system
[17:12] <dobey> robru: version-generation works fine with native
[17:12] <slangasek> robru: I agree; which means in this case it needs to be 3.0 (quilt) because that's the non-native package format that allows representing executable bits in debian
[17:14] <robru> slangasek: alright
[17:15] <davmor2> cwayne: how we doing?
[17:15] <slangasek> robru: ok. so as long as the train isn't going to choke on 3.0 (quilt) at the source prep stage, I think that's the way forward
[17:18] <dobey> :/
[17:20] <robru> slangasek: sounds fine then. Indeed the 'delete debian/source' instruction is in the context of "now we're upstreaming all the patches"
[17:24] <kyrofa> trainguards: I'm getting a "dependency wait timeout" for arm64 and ppc in silo 11. How do I debug that?
[17:26] <robru> kgunn: anpok: need this top-approved: https://code.launchpad.net/~mir-team/url-dispatcher/mir-release-0.14.0/+merge/262953
[17:26] <davmor2> cwayne: just got the message thanks trying now
[17:26] <dobey> kyrofa: golang-go.tools isn't built on those platforms currently it seems
[17:26] <slangasek> kyrofa: not sure about the 'timeout', but dependency wait is expected here because the package build-depends on toolchain bits that don't exist on those architectures; the problem is ignorable
[17:27] <robru> slangasek: if it's ignorable then why did the train explode on it? that means there's a regression from distro.
[17:27] <kyrofa> slangasek, ah, okay. Yeah I'd expect a better error, haha :) . Okay, ignoring!
[17:28] <camako> robru, I top-approved it
[17:28] <camako> kgunn, anpok ^
[17:28] <dobey> hmm, so it failed to build on those archs in vivid
[17:28] <dobey> and it hasn't been updated in ubuntu since then
[17:28] <slangasek> robru: unity-scope-snappy isn't in the distro yet, so it can't be a regression
[17:28] <slangasek> robru: (I checked this before opening my mouth :)
[17:29] <dobey> hmm, and there's not a new version in debian either
[17:30] <robru> kyrofa: why are you rebuilding?
[17:30] <kyrofa> robru, I just pushed up the debian/source/format. I'd like real packages built :P
[17:31] <robru> kyrofa: ok sorry I'm just trying to catch up here
[17:32] <kyrofa> robru, oh you're good. Yeah, with the dh-exec files not being executed correctly I ended up with packages using variable names as directory names, haha
[17:33] <robru> kyrofa: slangasek: ok yes so in this case since there is no existing release in ubuntu, train default is to watch all arches, so that's why it's erroring on this ignorable problem. it'll keep happening every time you rebuild until finally there's a release, then the *next* silo you do for this package will watch the right arches correctly.
[17:33] <kyrofa> robru, good to know!
[17:33] <kyrofa> robru, thank you :)
[17:34] <robru> kyrofa: there may be other issues you run into, generally speaking the train isn't good at building brand-new packages, there's a bunch of code paths that check distro in order to know what to do/expect.
[17:34] <robru> kyrofa: you're welcome
[17:34] <kyrofa> robru, ah, happy to exercise them!
[17:35] <robru> kyrofa: but yeah once you get that first release out the door, all subsequent ones should go a lot smoother
[17:35] <robru> kyrofa: keep an eye on the PPA for now, the depwait timeout is something like 2 hours, so you can save yourself 2 hours of wait time by ignoring the train dashboard status and going right to the source.
[17:35] <kyrofa> robru, honestly everything I've hit so far has been my own lack of debian packaging knowledge
[17:35] <robru> kyrofa: and my bad advice ;-)
[17:36] <kyrofa> robru, had you not said anything I wouldn't have learned what I learned today :)
[17:36] <robru> kyrofa: ha, you're welcome then :-P
[17:37] <kyrofa> robru, ;)
[17:59] <cjwatson> robru: depwait timeout> one hour rather than two (and a cron job rather than a timeout)
[17:59] <robru> cjwatson: you're talking lp side. I'm talking in the train. When the train is polling the PPA build states, it gives up after 2 hours.
[17:59] <robru> 2 hours of depwait anyway. any other state it'll happily poll forever.
[17:59] <cjwatson> oh right, fair enough
[18:15] <cwayne_> davmor2, any luck?
[18:19] <davmor2> installing the silo now cwayne
[18:21] <cwayne_> kk
[18:26] <davmor2> cwayne: I haz 8 count them 8 Icons Woohoo!!!!!!!!
[18:28] <davmor2> cwayne_: 8 icons and the modifications are still in place too \o/
[18:29] <davmor2> jibel, robru: ^ do we need to retest or should we just push it through?
[18:29] <robru> davmor2: what silo? what's going on?
[18:30] <robru> davmor2: generally speaking a rebuild requires a retest, unless it's a totally trivial change, then a quick smoketest should suffice.
[18:30] <davmor2> robru: silo 35 and a custom tarball for the fix for the 8 icons on upgrade for ota5
[18:31] <robru> davmor2: custom tarball changes? that sounds risky ;-) I'd retest
[18:31] <robru> davmor2: maybe not the full test suite but make sure it's actually fixing the issue.
[18:31] <davmor2> robru: yeah I'm particularly concerned as cwayne forgot to build the image with the fix in D'oh :)
[18:32] <robru> davmor2: yeah I think a retest is in order ;-)
[18:34] <cwayne_> +1, because I'm an idiot :)
[18:35] <cwayne_> sorry, been like a year since i'd done an MP based landing instead of just a custom tar
[18:39] <davmor2> cwayne_: why the tail?
[18:39] <cwayne_> ?
[18:40] <davmor2> cwayne_: you have an _ and there is a cwayne too just wondered why ;)
[18:41] <cwayne_> davmor2, ah, cus im on my laptop downstairs but i left my desktop on upstairs
[18:41] <cwayne_> and i never setup an irc proxy
[18:42] <davmor2> cwayne: then set one up muppet boy you do nothing else with your day now you don't build the images ;)
[18:42] <davmor2> cwayne_: too^
[18:42] <cwayne_> lol
[18:46] <davmor2> cwayne_: so mark it passed I don't know what the plan is to get them into the staging image though we would need sil2100 for that I assume unless robru knows how to do it :)
[18:49] <robru> davmor2: well I can hit publish on the silo, but I'm not up to speed on custom tarballs or building images.
[18:49] <cwayne_> id say we should wait for sil then
[18:49] <robru> cwayne: that'll be, like 12ish hours...
[18:49] <robru> cwayne: I mean next week
[18:50] <cwayne_> well, we generally dont push custom tars without his +1, and this landing should go alongside a custom tar
[18:50] <cwayne_> so if we have to wait for monday, i guess it is what it is..
[18:50] <cwayne_> davmor2, thoughts?
[18:50] <davmor2> robru: this has to land in the image for ota 5 for arale so it's not a normal landing I don't think
[18:50] <robru> cwayne: ok, I'm going to mark it not tested so I don't forget and accidentally publish it then. follow up with sil on monday
[18:51] <cwayne_> robru, sounds reasonable, thanks
[18:51] <robru> davmor2: are you saying it's urgent then? I thought ota5 was just delayed
[18:51] <davmor2> robru: I think it needs some wrangling,  No urgent to test so it's ready for Monday that is achieved
[18:52] <cwayne_> yeap
[18:52] <cwayne_> so we should be all set
[18:52] <cwayne_> for today i mean
[18:52] <cwayne_> thanks a lot for testing davmor2
[18:53] <davmor2> cwayne: is there someone we can ping in EU timezone to push the button on the tarball?
[18:53] <robru> davmor2: ok great, sorry I don't know more about custom tarballs
[18:53] <cwayne_> davmor2, well penk could monday
[18:53] <robru> davmor2: sil is EU ;-)
[18:53] <cwayne_> since it is his now anyway :)
[18:53] <davmor2> robru: no worries I'll ping sil2100 after :)
[19:01] <robru> qbot no
[19:01] <kyrofa> trainguards: I just added a few new branches to line 74 of the spreadsheet (same project). Can I get silo 11 reconfigured to use them?
[19:02] <kyrofa> trainguards: I don't believe I can do this myself-- please correct me if that's wrong
[19:02] <robru> kyrofa: you can do it yourself. the rules on this have changed recently and probably haven't been updated yet
[19:03] <kyrofa> robru, ah, nice! How do I do that?
[19:03] <robru> kyrofa: first click on any cell in your row. then at the top there's a menu "Landing tools > Assign/Reconfigure"
[19:07] <davmor2> robru: sil2100 left you a cryptic note on the silo 20150717/robru: This is QA approved by davmor, but needs to land in coordination with a custom tarball, publish later so definitely over to silo2100 :)
[19:08] <robru> davmor2: no I just wrote that myself.
[19:08] <davmor2> robru: ah okay
[19:08] <robru> davmor2: the date/name at the start of those notes indicates who wrote it and when
[19:09] <robru> davmor2: that was just there to indicate it was testing pass, but I officially set the silo to not testing pass so that the dashboard wouldn't burn a hole in my eyes with a big temping "PUBLISH THIS" neon sign
[19:09] <davmor2> robru: oops
[19:10] <kyrofa> robru, awesome, thank you, it works! :)
[19:10] <robru> kyrofa: you're welcome!
[19:12] <taiebot> Fate as decided i will not buy an MX4 :'(. Wanted to top up my paypal account to pay for the new phone. Got the call for my bank to validate the transaction but my Nexus 4 running UT refused to take the call.
[19:12] <taiebot> Oups wrong channel
[19:14] <kyrofa> taiebot, yeah, I learned the "cihelp" doesn't get your questions answered in other channels, too
[19:20] <sil2100> davmor2, cwayne: I'll copy over the fix to the snapshot and try to kick an image
[19:20] <sil2100> davmor2, cwayne: from my POV the new custom tarball can be freely published to the rc-proposed channel
[19:20] <sil2100> davmor2, cwayne: are the krillin and vegetahd ones ready as well?
[19:20] <sil2100> I just need to finish something up and I'll get right to it
[19:21] <davmor2> sil2100: awesome dude, wasn't sure if there was anything special needed
[19:22] <salem_> robru, hey, as boiko is out, would you trigger a rebuild in silo 44 for me?
[19:23] <davmor2> mzanetti: what happened to greybacks silo 007?
[19:43] <robru> salem_: you should be able to trigger builds, can't you?
[19:43] <salem_> robru, I tried, but it seems I have no permission
[19:43] <salem_> robru, "tiagosh is missing the Job/Build permission"
[19:44] <robru> salem_: what's your launchpad id?
[19:45] <salem_> robru, tiagosh
[19:45] <robru> salem_: ok, I added you. if you log out of jenkins, log back in, make sure during SSO you check off the lp teams, then log back in and you should be able to build
[19:48] <salem_> robru, awesome, thank you!
[19:49] <robru> salem_: you're welcome
[19:54] <kyrofa> trainguards: My build logs suddenly look like this: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-011/+build/7665329 . Is that normal?
[19:55] <kyrofa> trainguards: Meanwhile my silo just continually says "Currently building..."
[19:55] <robru> kyrofa: I've never seen this before
[19:56] <robru> maybe cjwatson knows ^^
[19:56] <kyrofa> robru, it's happened twice now-- I canceled the job and restarted it, and it happened again
[19:56] <robru> kyrofa: yeah don't do that
[19:57] <robru> kyrofa: "cancelling the job" doesn't have any effect on what's happening in the PPA.
[19:57] <kyrofa> robru, oops
[19:57] <robru> kyrofa: just let it sit for a bit. cjwatson mentioned the other day he was making some changes to the builders and there was a hiccup similar to this. this could be related.
[19:58] <robru> kyrofa: last time, the build log said finished while lp said it was still building. what I've never seen before is the weird unicode errors in the log
[19:59] <kyrofa> robru, yeah... suspicious indeed. Alright, I'll give it a breather
[20:11] <kgunn> camako: looks like we've still got an issue ?
[20:11] <kgunn> http://people.canonical.com/~platform/citrain_dashboard/#?q=ubuntu%2Flanding-004
[20:12] <kgunn> camako: ah...maybe just issue with device ?
[20:12] <kgunn> https://jenkins.qa.ubuntu.com/job/wily-boottest-mir/lastBuild/artifact/results/log/*view*/
[20:26] <camako> kgunn yea looks like it
[20:27] <kgunn> robru: ^ am i reading that correct ?
[20:29] <robru> kgunn: yeah boottest is known to be flaky
[20:29] <robru> cihelp: looks like almost all of these packages: http://people.canonical.com/~platform/citrain_dashboard/#?q=ubuntu%2Flanding-004 are stuck in proposed due to boottest, can somebody investigate?
[20:29] <robru> kgunn: actually something weird there, xorg-server doesn't look like it published, do you know what's up with that?
[20:29]  * kgunn looks
[20:31] <robru> kgunn: weird, the version from the PPA is in -proposed, but the train seems to be misreporting that it didn't publish. never seen that before
[20:32] <robru> kgunn: https://ci-train.ubuntu.com/job/ubuntu-landing-004-2-publish/71/artifact/packagelist_rsync_landing-004-wily/*view*/ here's the manifest even showing it publishing along with everything else
[20:33] <robru> kgunn: so I guess don't worry too much, but this will prevent the silo from auto-merging, we may have to manually poke the merge job once the migration completes. ping me if you notice the status change to only mention that xorg-server hasn't been published (and not mentioning anything else)
[20:33] <kgunn> robru: got it...
[20:52] <balloons> cihelp, can you disable utopic builds for sudoku app? sudoku-app-ci and sudoku-app-ci-autolanding
[20:55] <josepht> balloons: it looks like the utopic build is the only one, is that okay?
[20:55] <balloons> josepht, I see generic-mediumtests-utopic being run for it, as well as sudoku-app-utopic. You can keep sudoku-app-vivid
[20:56] <balloons> the framework requires vivid now essentially, so no more utopic can be run
[21:03] <josepht> balloons: I've pushed an MP for disabling the job in cu2d-config.  It will likely be Monday before it lands.
[21:19] <boiko> robru: could you please trigger an amd64 wily build of telephony-service on silo 43?
[21:19] <boiko> robru: trying to identify if the failure is a transient one or a real failure
[21:21] <robru> boiko: sure
[21:22] <boiko> robru: thanks
[21:23] <robru> boiko: you're welcome
[21:24] <cjwatson> robru: those are unicode but they aren't errors - that's just sbuild's box drawing, not rendered well here
[21:24] <cjwatson> kyrofa: almost certainly your build process has left something around on failure that for some reason we aren't managing to clean up correctly.  I've cancelled the build
[21:25] <cjwatson> (build, not job)
[21:25] <cjwatson> kyrofa: you should be able to see the full build log now
[21:26] <robru> cjwatson: ah, thanks for checking that
[21:26] <cjwatson> it's a bit odd that it didn't kill itself correctly, but I'm not investigating in that much detail on a Friday night :)
[21:27] <cjwatson> kyrofa: anyway there seems to be a missing Build-Depends: python3-requests or similar here, so maybe that will be enough to get things going properly
[22:18] <kyrofa> cjwatson, thanks for taking care of that! You're right, I forgot that dep
[23:35] <boiko> robru: coupd you please get libphonumber source package copied over from this ppa: https://launchpad.net/~boiko/+archive/ubuntu/source-uploads/+packages to silo 44?
[23:35] <robru> boiko: one sec
[23:36] <boiko> ah, source packages not supported in dual landings, hmm :/
[23:37] <robru> boiko: oh yeah right. you need to either do a wily landing and then later do a sync back to vivid landing, or make an MP for this package
[23:38] <boiko> robru: ok, I will check with _salem on monday how we want to do that, thanks anyway
[23:39] <robru> boiko: you're welcome!


[08:27] <Sebastien> grats hggdh :)
[08:28] <Flannel> ( https://lists.ubuntu.com/archives/ubuntu-irc/2016-April/001849.html )
[10:37] <bigcalm> Hi peeps :) I can never remember how to set factoids on lubotu3. !rat needs to be updated for #ubuntu-uk thus: rat is The Real Ale Train. A yearly Ubuntu UK loco event to celebrate friends, trains and ale. Saturday 10th September 2016 Hampshire, UK: http://loco.ubuntu.com/events/ubuntu-uk/3350-real-ale-train-2016/
[10:38] <popey> like that
[10:38] <bigcalm> :)
[10:38] <popey> I dunno how it gets approved though
[10:39] <bigcalm> Hopefully some nice bod will help us update it :)
[12:11] <k1l> !mutt is a small but very powerful text-based mail client for Unix operating systems. For more Informations on how to setup see https://help.ubuntu.com/community/mutt and https://wiki.ubuntu.com/Mutt
[14:08] <bigcalm> DJones: ping
[15:44] <dax> !rat
[15:44] <dax> !rat-#ubuntu-uk
[15:45] <dax> !no, rat-#ubuntu-uk is <reply> rat is The Real Ale Train. A yearly Ubuntu UK loco event to celebrate friends, trains and ale. Saturday 10th September 2016, Hampshire, UK: http://loco.ubuntu.com/events/ubuntu-uk/3350-real-ale-train-2016/
[15:45] <dax> popey, bigcalm: ^ done
[15:46] <dax> (assuming a lubot is like an ubot, it'll automatically sync over)
[15:49] <bigcalm> dax: thank you
 !rat
 rat is The Real Ale Train. A yearly Ubuntu UK loco event to celebrate friends, trains and ale. Saturday 10th September 2016, Hampshire, UK: http://loco.ubuntu.com/events/ubuntu-uk/3350-real-ale-train-2016/
[15:49] <bigcalm> dax :)
[15:50]  * bigcalm slithers away


[11:07] <alan_g> greyback: here's the MP for the features we discussed yesterday. Do the tests capture your requirements correctly? https://code.launchpad.net/~alan-griffiths/mir/terminate-and-abort-in-mir-Server-API/+merge/240236
[11:18] <greyback> alan_g: it addresses my main issue with run_mir, yes, thank you
[11:19] <alan_g> greyback: My plan is to retire run_mir and get qtmir using Server::run()
[11:20] <greyback> alan_g: suits me nicely
[11:22] <alan_g> greyback: I'll do the migration work with qtmir once I've got this landed, but may need some guidance on branches and testing.
[11:22] <greyback> alan_g: ok. qtmir's testing story quite weak, so I'll probably asking your guidance there :)
[11:23] <alan_g> Yeah, I guessed it was "build the whole stack and see if smoke comes out of phone"
[11:29] <greyback> mostly yeah
[11:38] <alan_g> is it lp:~mir-team/qtmir/devel-mir-next I should be looking at? (Or lp:qtmir?)
[11:50] <greyback> alan_g: lp:qtmir