[01:43] <tgm4883> rhpot1991, cause you deleted !hi
[02:19] <rhpot1991> tgm4883: ah, I deleted it cause zinn does that himself now
[02:19] <Zinn> Hi rhpot1991, something I can help you with today?  I am a bot, use !help to see what I can do.
[19:21] <javatexan> does blueray work yet in mythbuntu?
[19:21] <rhpot1991> javatexan: depends on your definition of "work"
[19:22] <rhpot1991> in theory if you had a way to get video from your BR then it can play
[19:22] <rhpot1991> javatexan: I tried to PM you and got some random spammy thing
[19:23] <javatexan> pidgin has been flaky lately
[19:24] <rhpot1991> its asking me some bible question, which I will not take the time to entertain, pm me
[19:36] <Daviey> javatexan: Feel free to buy me a BR player, and i'll test it for you :)
[19:37] <javatexan> lol
[19:37] <javatexan> I feel your pain....darn economy, no extra to play with new tech toys
[19:39] <mrand> They are onsale for $80, plus or minus.
[19:39] <rhpot1991> I splurged and went for a burner when I got mine
[19:40] <rhpot1991> it was on sale as well
[19:40] <Daviey> my frontend doesn't even have a cd drive, so i'd need to rip it onto the backend anyway :S
[19:41] <rhpot1991> Daviey: thats where all your media should live anyways
[19:41] <mrand> Daviey: I do the same.
[19:41] <rhpot1991> not to mention you can't play right from the disc at all
[19:41] <Daviey> really?
[19:42] <mrand> Daviey: blu-ray is still problematic.
[19:47]  * javatexan nudges and says but blu-ray is just using java for DRM
[19:49] <rhpot1991> IIRC the bd+ discs wont play in something that doesn't have an ethernet port too, needs to call home
[19:53] <Daviey> :(
[20:19] <javatexan> :( is right
[20:19] <javatexan> so you have to connect BR players to your network before it works?
[20:29] <mrand> javatexan: I don't know that a net connection is required except in cases when certain disks won't play (i.e., the disk requires that the player be updated).
[20:32] <major_> hi, Mythbuntu is not able to find any videos... the path ive got set for them is /home/major/BigBoX/multimedia/movies. I press m and scan and still no videos... bigbox is another disk mounted for user:major group:root, i can cd to the directory and watch the videos with any problem from thunar... ive been reading the forums and the FAQs with no success, versions of the program are the latest
[20:43] <rhpot1991> major_: sounds like permissions
[20:44] <rhpot1991> !blank% | major_
[20:44] <Zinn> major_: If you try to watch tv and are greeted with a blank screen and a return to the menu then please check the permissions on your recording directory.  It should be owned by mythtv:mythtv, have permissions of 775, and not be inside your home directory
[20:44] <rhpot1991> set them to the permissions there
[20:49] <major_> :o directories must be owned by mythtv?
[20:49] <major_> why is that if may i ask?
[20:50] <major_> some sort of security thing?
[20:51] <rhpot1991> mythtv is the user and group
[20:51] <rhpot1991> mythtv:mythtv user:group
[20:56] <major_> i mean, why is mythtv unable to read other folders?
[20:56] <major_> is for security concerns?
[21:00] <tgm4883> major_, I haven't looked into it farther than there are issues with it in the home dir


[00:18] <OvenWerks> zequence: Inlining menus does not seem to work on xfce
[02:29] <OvenWerks> zequence: I have also been unable to change a separator from ____ to some text.
[15:03] <zequence> OvenWerks: We might not be able to do all changes to the desktop files by the time for next release, so the menu may need to be as is until then.
[15:04] <zequence> We should aim at making the meny work with the future desktop files, not the ones we have now
[15:05] <zequence> I forgot about the custom freedesktop categories, that just begin with X-. Should not be too hard to get X-DAW accepted upstream
[15:05] <holstein> we should be able to get what we need up there
[15:05] <holstein> with the freedesktop folk
[15:06] <holstein> im sure others are having the same issue.. and then, the dev's can just put them where they want them, and we can respect that..
[15:06] <holstein> rather than having all the audio folk deal with it on their own
[15:06] <holstein> not that there are that many.. or that many complaining about a menu..
[15:14] <holstein> well, i joined the email list, and posted... i'll let you know if i hear anything
[15:15] <holstein> i just cant imagine this being exclusive to our community.. its gotta be a linux-wide issue that we may be able to address upstream
[15:15] <zequence> holstein: We're not really at the point where we are proposing any changes upstream yet, since we do not have a definitive list of stuff to recommend to be changed
[15:16] <zequence> But, of course, if you can get some answers on how we can do that, that would be great
[15:17] <holstein> i think *everyone*, including the creators of the  applications can agree, there are no catagories for the applications
[15:17] <zequence> We should first finish the categorization of all packages that have desktop files in the Debian sections sound, graphics and video
[15:17] <holstein> sure.. but that would take care of that
[15:17] <zequence> There are some categories that are not being used
[15:17] <zequence> What would take care of that?
[15:18] <holstein> the creators can catagorize the packages, in compliance with freedesktop standards, that would just work for everyone
[15:18] <holstein> rather than, our "band-aid" for ubuntustudio
[15:18] <zequence> IT's not band-aid
[15:18] <holstein> its specific to just our repos
[15:18] <zequence> It's us doing what the upstream devs have not done properly first
[15:18] <holstein> yup
[15:18] <zequence> It's for all Debian, and then for all Linux
[15:18] <holstein> and, it may be a similar amount of effort to just do it up there
[15:18] <zequence> We don't do the changes in Ubuntu. We do them in Debian
[15:18] <zequence> Where?
[15:19] <holstein> upstream
[15:19] <zequence> Someone needs to change the desktop files
[15:19] <holstein> right
[15:19] <zequence> And, that's what we are doing
[15:19] <holstein> the creators of them can, if there are appropriate catagories
[15:19] <zequence> There are already a lot of them, that aren't being used
[15:20] <holstein> yup.. OvenWerks and i looked at them
[15:20] <zequence> Then, we need to figure out, while we do the categorization, what else we need to add
[15:20] <holstein> i dont think it would be much effort to clean them up
[15:20] <holstein> add/remove
[15:20] <zequence> You're welcome to participate in that
[15:21] <holstein> thanks
[15:22] <holstein> i am participating right now, by joining that mailing list, and asking about the categorization there
[15:22] <zequence> Yes, of course, but I meant to do the actual categorization work
[15:23] <zequence> There's one example for ardour3 on how it's done https://wiki.ubuntu.com/UbuntuStudio/Wily/AudioApplications
[15:23] <holstein> right.. but, i think we have been batting around categories for a while
[15:23] <zequence> Ross Gammon made some suggestions on the mail list on how to find which package has a desktop file
[15:23] <holstein> i think, we just need to nail something down, and then, someone/s can just implent the changes
[15:23] <zequence> That's exactly what that page is about
[15:23] <holstein> there are *many* suggestions
[15:23] <zequence> No, there aren't
[15:23] <holstein> zequence: cool
[15:24] <holstein> im going out now.. just let me know when its all settled, and i'll let you or OvenWerks know what i hear on that list
[15:24] <zequence> Sure
[15:24] <holstein> im sure theres a wiki page about it..
[15:24] <zequence> About what?
[15:25] <holstein> the proposed menu structure..
[15:25] <holstein> what goes where, and why
[15:25] <holstein> and, who decides.. and then, we just make the chagnes
[15:25] <zequence> Yes, and you can read all about it on the mail list. But, we are not there yet where we can start working on the menu properly
[15:25] <zequence> Since the categories haven't been dealt with in the actual desktop files
[15:25] <holstein> yes.. "properly"
[15:26] <holstein> so, outline that, and we'll have at it..
[15:26] <holstein> or, OvenWerks can?
[15:26] <zequence> This is the order in which we need to do stuff, ok..
[15:26] <zequence> 1. we do the categorization for all desktop files in the Debian/Ubuntu repos in these three pages:
[15:26] <zequence> https://wiki.ubuntu.com/UbuntuStudio/Wily/AudioApplications
[15:26] <zequence> https://wiki.ubuntu.com/UbuntuStudio/Wily/GraphicsApplications
[15:27] <zequence> https://wiki.ubuntu.com/UbuntuStudio/Wily/VideoApplications
[15:27] <zequence> Once we are done, we make changes to desktop files upstream
[15:27] <zequence> Then, or at the same time, we recommend changes in freedesktop categories
[15:27] <holstein> sounds great
[15:27] <zequence> Finally, we are able to make the menu auto-populate from the existing desktop files
[15:28] <zequence> We can draft the menu now, but we can't make it work until the desktop files have been changed
[15:29] <holstein> having the sections, and knowing what goes where..
[15:29] <zequence> Yeah
[15:30] <holstein> seems as simple as "ardour - audio - DAW" or whatever.. and someone just has to be in charge of that categorization.. and i dont have any preference, personally
[15:31] <holstein> i dont use a menu, so, it doesnt bother me.. but, at some point, someone just has to make the call.. and i was just saying *if* the categories were decided, then, that categorization could be done, in many cases, by the creators of the applications
[15:31] <holstein> i have run into the issue with trying to burn a data iso with brasero, and having to find it in an audio menu.. but, its got to go somewhere
[15:31] <zequence> Well, if that were true, they would make use of the ones that already exist
[15:32] <holstein> zequence: i dont think anyone has offered to address it up there
[15:32] <zequence> Freedesktop is not the main problem. The actual desktop files are
[15:32] <holstein> zequence: the ones that already exisit actually look like maybe someone from myth, etc, has been there
[15:33] <holstein> well, i think we could get into a chicken or egg things, here. but, im not suggesting no one edit a desktop file
[15:33] <zequence> It's not like that, once you realize which is the front and back of the horse
[15:33] <zequence> WHich, I'm not sure you are doing yet
[15:33] <holstein> all im saying is, the categories we, ubuntustudio, and the actual creators of many of these applications, dont have a suitable menu item in freedesktop
[15:33] <holstein> so, they dont catagorize them, as such
[15:34] <zequence> I have already stated many times, that there are suitable freedesktop categories that aren't being used
[15:34] <zequence> Also, devs upstream are probably not putting a lot of focus on this
[15:34] <zequence> This is why we have to do the work, since no one else will
[15:34] <holstein> if there are suitable ones, then, there shouldnt be any problem..
[15:35] <zequence> The problem is in that they aren't being used properly in the desktop files
[15:35] <zequence> Also, we may need a few additional ones
[15:35] <holstein> additional what?
[15:35] <zequence> Freedesktop categories
[15:35] <holstein> you mean, additional ones that are *not* in the suitable set you mention?
[15:35] <zequence> ones that don't exist yet
[15:35] <holstein> becuase *thats* what im talking about
[15:35] <zequence> But, only a very few
[15:36] <zequence> And, those aren't the main problem, as I've been trying to convey here
[15:36] <zequence> The main problem is that the ones that exist aren't being used
[15:36] <zequence> Get it?
[15:36] <holstein> who's not using them?
[15:36] <holstein> debian? ubuntu?
[15:37] <zequence> The original devs for each piece of software that has a desktop files
[15:37] <zequence> file*
[15:37] <holstein> i think the entire issue is going to be more and more challenging as things just move away from a menu.. a traditional menu
[15:38] <holstein> anyways, im sure its more challenging than i understand
[15:39] <zequence> At first glance putting a category on something may seem trivial, but the more you categorize, the trickier it gets
[15:39] <holstein> i mean, if we are talking about just you and OvenWerks editing a couple thousand desktop files in the debian repos. thats not cool
[15:39] <holstein> i dont edit those.. i dont know that i can, or should
[15:39] <zequence> I'm not sure OvenWerks is about to change any desktop files-
[15:39] <holstein> if its something we can file bugs about, and get someone else to address, easily, maybe thats the way
[15:40] <zequence> But, I can do that in Debian
[15:40] <zequence> The big work is in drafting the suggested changes, which is what the wiki pages are about
[15:40] <holstein> im not following
[15:40] <zequence> I have access to the Debian multimedia sources
[15:40] <holstein> as i read above, the suggested change is "fix what isnt implemented"
[15:41] <zequence> So, I can make changes there in desktop files
[15:41] <holstein> the broken-ness..
[15:41] <holstein> if they are already categorized.. and those desktop files are just "bad"..
[15:41] <zequence> holstein: Take a look at this page https://wiki.ubuntu.com/UbuntuStudio/Wily/AudioApplications
[15:41] <zequence> There are two columns of real importance
[15:41] <zequence> FDC (Freedekstop categories)
[15:42] <zequence> and "Suggested FDC"
[15:42] <zequence> We first need to check which freedesktop categories are being used for each package
[15:42] <zequence> Then, we suggest additions/changes for each of those
[15:43] <zequence> Once we have made suggestions for each, and feel ok with them, we do the changes upstream in Debian
[15:43] <zequence> I will need to talk with them about it, and as long as no one there disagrees..
[15:43] <holstein> sure. i'll add a "leave it as-is, only working" column
[15:43] <zequence> That will make our menu work
[15:44] <zequence> Right, they were "Current FCD", and "Suggested FDC". Anyway
[15:45] <zequence> holstein: Don't add columns to the wiki
[15:45] <zequence> I've made that list with a script
[15:45] <zequence> "leave as is" can be written under "Suggested FDC"
[15:46] <zequence> holstein: If you want to help, you can help by researching which categories are used in the existing desktop files
[15:46] <zequence> That's where we need to start
[15:47] <holstein> zequence: well, i was joking
[15:47] <holstein> zequence: they are publically editable
[15:49] <holstein> what i have time for, right now, is to see where that email goes.. and, i'll check back in
[15:58] <zequence> I'm going to script the process of listing existing freedesktop categories
[15:59] <zequence> Would reduce the work load a lot
[18:33] <elfy> zequence: I see that I'm still listed on release team - going to remove myself from that now, was only needed for the tracker. If in future you want any help with that just shout.
[20:23] <zequence> Ok, elfy. Thanks a lot for all the help.
[20:58] <OvenWerks> zequence: our graphics/publishing/photographics menus already use categories quite heavily. I am not so sure about the 2d/3d categories though. I will try adding them on my own machine to see where things go. It seems that the audio area is the worst one.
[23:07] <OvenWerks> zequence: I think we have time to renew the menu. I can at least put all the existing categories in there and whatever apps we have to place by hand is ok. Then we have a list of apps that need work.
[23:08] <OvenWerks> zequence: debian changes the catagories when they package anyway. Perhaps we can get them to correct categories rather than deleting wrong ones.
[23:11] <OvenWerks> zequence: I think we should remove all the extra software desktop files. We will no longer really have room for them
[23:12] <OvenWerks> zequence: also in menuless systems they all show up in a clump which is confusing. One installer is all we need.


[01:59] <mpt> Goooooooooooooooooood afternoon Launchpadders!
[03:10] <jamesh> mpt: just a reminder that bug 64080 is in your court again.
[03:10] <Ubugtu> Malone bug 64080 in launchpad "Highlighting of active application in facets menu has broken" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64080
[03:20] <mpt> jamesh, yes thank you, I was trying to get to sleep last night when I realized it might be a CSS problem rather than a view problem
[04:01] <doug> ah...
[04:02] <doug> what's responsible for the general prettiness and utility of the launchpad?
[04:03] <doug> as far as the final HTML rendering goes...
[04:04] <doug> one package?  or a bunch?
[04:12] <jamesh> doug: Launchpad is built on top of the Zope component framework.  We use zope page templates to build the pages.
[04:13] <jamesh> the design has evolved over time
[04:15] <doug> so, someone wants to enter a feature...
[04:15] <doug> they go to some form, and fill it out
[04:15] <doug> that goes into a database
[04:15] <doug> and, say, a report generator can show you features entered over the last week..
[04:15] <doug> what components handle those types of operations?
[04:16] <jamesh> we use an object relational mapper called SQLObject for pretty much all of the database access
[04:16] <jamesh> which lets us treat records in the various tables as Python class instances
[04:16] <jamesh> makes it pretty easy to build the pages
[04:18] <jamesh> http://www.sqlobject.org/ <- in case you haven't found it with google yet :)
[05:43] <doug> well
[05:43] <doug> so you're saying that's custom code, basically.
[06:14] <viyyer> hi.. I had some translations on gnomebaker on rosetta
[06:14] <viyyer> it seems to have been close
[06:14] <viyyer> can I get the po files?
[06:15] <viyyer> so that I can submit it to gnomebaker?
[06:17] <viyyer> and why is there no credit on the translations I contributed?
[06:19] <spiv> viyyer: https://launchpad.net/products/gnomebaker/main/+pots/gnomebaker/hi/+export should let you get the po files.
[06:20] <spiv> Ask carlos or jordi about the credit issue when they're around.  I think there may be a known bug there.
[06:21] <viyyer> spiv, will do..
[06:21] <viyyer> jordi,
[06:21] <viyyer> checking it after long time..
[06:21] <viyyer> there are more stings to be translated there ...
[06:23] <viyyer> string actually
[06:53] <mpt> jamesh, this may be a silly question, but is it safe to delete a standalone branch once I have imported it into my local repository?
[07:37] <jamesh> mpt: in answer to your question: if there are no uncommitted changes in your standalone branch, and you've branched it into the repository, then you can delete the standalone branch
[07:57] <_thumper_> morning all
[08:20] <mpt> thanks jamesh
[08:20] <mpt> hi _thumper_, and welcome :-)
[08:20] <_thumper_> mpt: Nelson is nice, we thought about that but wanted to be near a university
[08:21] <mpt> ok, branch has landed, time for me to go home
[08:22] <mpt> _thumper_, for me, the university being away from home was part of the attraction of going to university :-)
[09:00] <carlos> morning
[09:25] <mpt> Yay for dial-up!
[09:36] <jamesh> mpt: maybe you should get a different DSL modem
[09:43] <mpt> nothing wrong with my modem, just the ISP
[11:21] <kristog> hello :)
[11:22] <carlos> kristog: hi
[11:28] <kristog> i was accepted as ubuntu member in the last CC. I didn't join ubuntumembers in time (before the CC meeting), now i'm in (thank you elmo) but until now my @ubuntu.com alias doesn't work.
[11:30] <Ubugtu> New bug: #64132 in rosetta "rosetta export truncates plural forms line (was: update-manager dont start)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64132
[11:40] <kristog> carlos: no idea about my problem?
[11:41] <carlos> kristog: sorry, I was busy with other things and didn't see your question
[11:41] <carlos> kristog: about the email alias, it takes one or two days to propagate it to the mail server since you are member of the team
[11:42] <kristog> carlos: no problem :) ok, i will wait :)
[11:42] <kristog> thank you
[11:43] <carlos> if you are waiting more than two days, ask the admins (elmo, Znarl, Spads)
[11:43] <carlos> you are welcome
[11:48] <kristog> carlos: elmo has accepted me ~2 days ago
[11:48] <carlos> danilos: ping
[11:48] <danilos> carlos: pong
[11:49] <carlos> kristog: then check it with the admins...
[11:49] <kristog> carlos: ok, thank you :)
[12:29] <Ng> carlos: if you mail<EMAIL_ADDRESS>it'll go into our sysadmin queue and someone will take a look
[12:30] <carlos> Ng: should we use it also for Ubuntu requests?
[12:30] <carlos> I was not sure if that's only used by Canonical internal requests
[12:31] <Ng> carlos: basically anything that requires sysadmin intervention is suitable to go in there
[12:31] <carlos> ok, next time, I will point people to it
[12:31] <carlos> thanks
[12:39] <kristog> so i should mail rt@?
[12:40] <carlos> kristog: yes, please
[12:40] <kristog> ok
[12:57] <ddaa> Good beginning of work day
[12:57] <ddaa> (can't say good morning with a straight face, it's 1pm...)
[01:26] <carlos> later!
[02:05] <ddaa> _thumper_: ping
[02:05] <_thumper_> ddaa: pong
[02:06] <ddaa> how's it going today?
[02:06] <_thumper_> good, although was out for part of the morning
[02:06] <_thumper_> so no more questions yet
[02:06] <ddaa> still busy downloading the context?
[02:07] <_thumper_> uh ha
[02:07] <ddaa> is that a .nz idiom?
[02:07] <_thumper_> sort of
[02:07] <ddaa> what does it mean, then?
[02:07] <_thumper_> uh ha -> yes
[02:08] <_thumper_> there was one bug of interst
[02:08] <_thumper_> talking about bzr branch lp://product and what it points to
[02:09] <ddaa> ok, the boss just came down on me with some pretty trivial fix he wants for six months ago, so I thought it would be something good for you to cut your teeth on if you were idle.
[02:09] <_thumper_> want to send it through, I'll take a look
[02:10] <_thumper_> gotta be more interesting than just reading specs et al
[02:11] <ddaa> that, should point to product.development_focus.series_branch
[02:11] <ddaa> let's just take that to a private chat
[03:07] <Keybuk> ya know, I reckon about 10% of people put their own name in the "Name" box when filing a spec
[03:12] <salgado> ddaa, around?
[03:17] <ddaa> salgado: what can I do for you?
[03:18] <salgado> hi ddaa. I'm reviewing one of jamesh's branch and am wondering why do we have the +source and +sourceadmin pages
[03:18] <salgado> is +sourceadmin the one that is only meant to be used by you?
[03:18] <ddaa> yes
[03:19] <salgado> is it still needed?
[03:19] <ddaa> i think it's mostly for historical reasons, like it the past +sourceadmin had fields about arch details, and maybe the permission system was not fine-grained enough.
[03:20] <ddaa> the +sourceadmin functionality is still very much needed, but if jamesh thinks it's not necessary to have have a separate page anymore, I trust him.
[03:20] <ddaa> In particular, privileged users need to be able to set the importstatus from the +source page
[03:21] <ddaa> for things like approving imports for production
[03:22] <salgado> ddaa, yeah, I was confused because I didn't notice it had been merged with the +source page, but I just noticed how it was done and if you have the necessary rights you'll be able to do everything you need from the +source page
[03:23] <ddaa> salgado: jamesh is quite aware of the various functional issues of code.lp.net, he can be trusted to make sensible calls IMO
[03:23] <salgado> agreed
[03:23] <salgado> but since I probably won't find him at this time here, I thought it was a good idea to check with you
[03:24] <ddaa> you did well, I appreciate that very much
[03:34] <ddaa> salgado: another thing to check for, is that privileged users can tweak the import details regardless of the importstatus, while normal users can only do it if the import has not been approved for sync.
[03:34] <ddaa> though I insisted enough on that point with jamesh that I would be very surprised if he got it wrong
[03:34] <sabdfl> matsubara: kiko around?
[03:35] <matsubara> sabdfl: nope, he'll be back on monday only
[03:35] <matsubara> sabdfl: <kiko> I'm on leave till monday, but call me if you need me
[03:36] <salgado> ddaa, yeah, once the import has been certified the +source page is only visible for admins
[03:43] <SteveA> matsubara: kiko has monday registered as a vacation day
[03:44] <SteveA> matsubara: did he say he'd be around *on* monday, or after monday?
[03:45] <salgado> he said he'll be back Tuesday, AFAIR
[03:45] <matsubara> SteveA: that's is the topic in #async, but I guess he'll be back only on monday afternoon/evening.
[03:45] <matsubara> SteveA: I mean back to So Carlos.
[03:45] <SteveA> ok
[03:45] <SteveA> thanks
[03:48] <ddaa> Somebody, please quick review this almost-trivial patch so I can put it in the DBA queue. It adds a Branch.date_created column. https://devpad.canonical.com/~andrew/paste/file6eQS7J.html
[03:50] <ddaa> salgado: SteveA: can you review that?
[03:51] <ddaa> _thumper_: you can look at it as well :)
[03:51] <_thumper_> ddaa: I am as we speak
[04:01] <Keybuk> sabdfl: blueprint query ... how do I see the list of proposed specs for uds-mv ?
[04:03] <matsubara> Keybuk: https://features.launchpad.net/sprints/uds-mtv/+specs
[04:04] <Keybuk> that's the list of Accepted ones
[04:04] <Keybuk> it looks like it's the "Driver can't use /+settopics" bug
[04:04] <Keybuk> someone needs to change the registrant to be Ubuntu Technical Board
[04:10] <sabdfl> Keybuk: you can't see https://features.launchpad.net/sprints/uds-mtv/+settopics
[04:10] <sabdfl> ?
[04:11] <sabdfl> hmm.... needs launchpad.Driver not launchpad.Edit
[04:11] <Keybuk> yeah, I get a "SORRY j00 r n0t l33t" page
[04:11] <sabdfl> Keybuk: well, there's of course some truth to that
[04:11] <sabdfl> ;-)
[04:12] <sabdfl> matsubara: pls could you whip up a quick fix to that please?
[04:12] <matsubara> sabdfl: sure
[04:12] <sabdfl> hmm... let me review it
[04:12] <sabdfl> will need:
[04:13] <sabdfl>   - launchpad.Driver permission for ISprint (see ReleaseAndSeriesDrivers)
[04:14] <sabdfl>   - change +settopics to launchpad.Driver rather than launchpad.Edut
[04:14] <sabdfl>   - also, check the code which auto-approves nominations from drivers
[04:15] <sabdfl> there's code in the productseries / distrorelease system to auto-approve a nomination of a feature by a driver
[04:15] <sabdfl> we need the same for sprints if it is not already there
[04:17] <sabdfl> ah: browser/specification.py line 600:
[04:17] <sabdfl>         if check_permission('launchpad.Edit', sprint_link):
[04:17] <sabdfl>             sprint_link.acceptBy(user)
[04:17] <sabdfl> needs to be launchpad.Driver
[04:17] <sabdfl> matsubara: sound OK?
[04:17] <matsubara> sabdfl: yep
[04:17] <sabdfl> thanks
[04:46] <stub> ddaa: Do you want me to land the Branch.date_created DB patch?
[04:46] <stub> Probably as fast for me to write it than review it
[04:47] <ddaa> stub: there's some non-trivial sample data tweaking
[04:47] <stub> Just adding a new column?
[04:47] <ddaa> I made it not-NULL to correctly represent branches created before adding the column
[04:48] <ddaa> and tweaked the sample data so only the most recent branches there have a non-NULL date_created
[04:48] <ddaa> also there's the comments.sql patch, I'd much prefer if you reviewed it, and then landed it if you are happy with it
[04:48] <ddaa> actually
[04:48] <stub> If you want to make life difficult. I would have just filled in a date for all the existing branches to avoid all the special cases that will be needed evermore.
[04:48] <ddaa> I made it not-not-NULL
[04:49] <ddaa> I love my code and my data correct.
[04:49] <stub> (which is what I'll be doing with all the other objects)
[04:49] <ddaa> If that means a bit more complicated a life, so be it.
[04:50] <stub> I'll have to think about that anyway - it will mean branch will be different to every other table with the column in the database.
[04:50] <ddaa> your call to overrule that, I made my part of the job
[04:50] <ddaa> I understand that not everybody shares some of my world views
[04:53] <ddaa> but I'd rather not end up displaying bogus date_created to the end user
[04:53] <ddaa> another way would be having a date_created for sorting, and a display_date_created for display...
[04:53] <ddaa> I think one nullable column is simpler
[04:54] <stub> Just hardcode the date - if the date is before X, it is fake so I shouldn't display it.
[04:54] <ddaa> I think that amounts to the same amount of special casing in the code.
[04:54] <stub> Means you can sort by datecreated for a start
[04:55] <stub> And it is only special case if you care about not displaying the bogus date
[04:55] <ddaa> nope, you can't because you have a bunch of equal datecreated values
[04:55] <ddaa> so you need to break this tie by using the id as a secondary sort key
[04:56] <stub> ddaa: I will ensure all the datecreated's are 1 second apart
[04:56] <_thumper_> ddaa: to throw my 2c in, I'd go for a not-NULL field
[04:56] <_thumper_> keep the db consistent
[04:56] <_thumper_> have some old epoc
[04:56] <ddaa> stub: fine then, it's just a bit above the level of sql-foo that I can do without having to dig into the documentation and experiment.
[04:57] <stub> Also, ORDER BY date_created,id will list all the oldest branches last instead of first
[04:57] <stub> (in postgresql anyway)
[04:57] <ddaa> stub: just please document the cut-off date-created value somewhere.
[04:57] <stub> ddaa: Will do
[04:58] <ddaa> stub: thank you
[05:02] <stub> date_created is bogus anyway in some ways, as it is the time the branch was registered with launchpad, not the time the branch was created ;)
[05:03] <ddaa> stub: I pointed that out in comments.sql
[05:04] <ddaa> still, I think the date the branch was registered into launchpad can be significant
[05:04] <stub> yup
[05:04] <ddaa> _thumper_: BTW, since you're poolie's minion
[05:05] <ddaa> _thumper_: maybe you can pick up the discussion I started about bzr recording branch points in the history
[05:05] <_thumper_> yeah...
[05:05] <_thumper_> wanna point me at the current discussion?
[05:06] <ddaa> _thumper_: abently and j-a-meinel contributed to it. It seems quite doable, my biggest issues is that unless this information is used somehow to improve the life of bzr users, they will have no incentive to use the tool in the right way to record this information correctly.
[05:07] <ddaa> So we would end up with bogus branch points, which is worse than no branch points at all IMO.
[05:09] <ddaa> _thumper_: http://thread.gmane.org/gmane.comp.version-control.bazaar-ng.general/16884/focus=17014
[05:09] <_thumper_> ok, got it
[05:13] <ddaa> doh! Just realised that my plan to efficiently support simultaneous adds+modify conflicts with my plan to handle renames... might need to change the data model a bit... :(
[05:55] <Ubugtu> New bug: #64373 in launchpad "[wishlist]  download gpg keyring for a team" [Undecided,Unconfirmed]  http://launchpad.net/bugs/64373
[06:12] <carlos> danilos: hi
[06:12] <carlos> danilos: meeting time?
[06:12] <danilos> carlos: sure, sorry I am late
[07:39] <carlos> see you!
[08:15] <sivang> hello
[08:16] <sivang> bradb: Will (are do we already) we have anonymous bug reporting capabilities in LP ?
[08:16] <sivang> or in, malone for that matter.
[08:16] <sivang> BjornT: ^^
[08:16] <bradb> sivang: No, sorry. No firm decisions about it either way.
[08:17] <bradb> sivang: bug 50653
[08:17] <Ubugtu> Malone bug 50653 in malone "Malone should support craigslist-style anonymous bug reporting" [Undecided,Confirmed]  http://launchpad.net/bugs/50653
[08:17] <sivang> bradb: I see, not even a cloak room for that?
[08:18] <bradb> no cloakroom yet either
[09:03] <sivang> bradb: if someone openes a bug on a product, and his sub'd to all bugs of the product, will he get notified of his own reported bug?
[09:04] <bradb> sivang: yeah.
[09:07] <sivang> bradb: anyway to disable this?
[09:09] <bradb> sivang: no way to disable it currently, sorry. bug 548.
[09:09] <Ubugtu> Malone bug 548 in malone "don't send mails about changes to the people doing the change" [Medium,Confirmed]  http://launchpad.net/bugs/548
[09:09] <sivang> bradb: I see, thanks
[09:10] <bradb> sivang: it'd be easier to filter all mail from changes made by you though...just filter all mail From: you that has an X-Launchpad-Bug header.
[09:20] <moz-art> hi
[09:21] <moz-art> somebody speak spanish?
[09:25] <jordi> yes
[09:25] <jordi> hola
[09:25] <jordi> moz-art: qu tal?
[09:26] <moz-art> jordi, hola, ac estaba viendo la pgina de shipit.ubuntu.com...y tena una duda
[09:26] <moz-art> :P
[09:26] <moz-art> son gratuitos los cd's o hay que pagar por ellos?
[09:26] <jordi> son gratutos
[09:27] <jordi> aunque si pides una cantidad "exagerada", quizs se te deniege el envo, o te pidan ms ifnormacin para ver para qu necesitas tantos
[09:27] <moz-art> tons con 3
[09:27] <moz-art> xD
[09:27] <moz-art> :P
[09:27] <jordi> tons?
[09:28] <jordi> moz-art: pedir muy pocos quizs salga ms caro en proporcin que pedir la cantidad estndard.
[09:28] <moz-art> jajaja
[09:28] <jordi> moz-art: no te sigo...
[09:29] <moz-art> jordi: tons 10?
[09:29] <moz-art> :S
[09:29] <moz-art> xD
[09:29] <jordi> qu quiere decir tons?
[09:31] <moz-art> jordi: entonces
[09:40] <jordi> oh
[09:40] <jordi> moz-art: yo pedira lo estndard
[09:40] <jordi> moz-art: cuantos pensabas pedir?
[09:40] <moz-art> 5 Cd's
[09:41] <jordi> 5 o 10 est bien
[09:41] <jordi> si pides 10, podrs repartir a algn amigo de ms ;)
[09:42] <moz-art> jordi: ^^, sip, de hecho para eso los quiero, que todo la gente de zihuatanejo, gro. use linux :P
[09:42] <jordi> ok
[09:42] <moz-art> jordi: yo ya tengo la distro que ped...pero no pienso dar mi cd
[09:42] <jordi> quizs quieras pedir 10, pero alguno para AMD64 o mac, si tienes gente que usen esos sistemas
[09:42] <moz-art> xD
[09:42] <jordi> he he, claro, smlemente pide unos pocos ms
[09:42] <moz-art> nop, ac puro PC
[09:43] <jordi> y si te hacen falta ms, puedes copiarlos.
[09:43] <moz-art> :O
[09:43] <moz-art> :D
[09:43] <jordi> ok
[09:43] <jordi> voy a ir a cenar
[09:43] <jordi> disfruta de tu pedido ;)
[09:48] <moz-art> :D
[09:56] <agent> how does one upload more than one attachment with a messege in launchpad?
[10:16] <bradb> agent: the hard way, for now, unfortunately (i.e. one submit per attachment)
[10:18] <bradb> hrm
[10:29] <flacoste> salgado, BjornT, or any other reviewer: I'd like a quick review of a small improvements to find_portlet: https://devpad.canonical.com/~andrew/paste/fileW2Rn7x.html
[10:45] <salgado> flacoste, looks good to me
[10:45] <flacoste> salgado: thanks!
[11:27] <salgado> flacoste, how do I run the tickettarget.txt test which is inside interfaces/ftests/?
[11:27] <flacoste> test='tickettarget'
[11:27] <flacoste> or canonical.launchpad.interfaces.ftests.test_tickettarget
[11:27] <flacoste> salgado: ^^^
[11:29] <salgado> flacoste, cool, thanks


[10:02] <jfi> Hi, is it possible to 'close' a merge request? I would like to no more request it, but keep the comments for reference which appear to not be the case for 'delete proposal to merge'. The possible status are 'Needs review'/'Work in progress'/'Merged', nothing like 'Abandonned'
[10:06] <mgz> jfi, I use merged or rejected depending on which fits best
[10:06] <mgz> I see no problem in rejecting my own mps if I realise after submitting it's the wrong approach or something
[10:07] <wgrant> Only a reviewer for the target branch can set it to Rejected, I believe
[10:07] <jfi> mgz, 'merged' is not appropriate, 'rejected' should be nice but unfortunely I don't have this status in the list:( Maybe due to permission?
[10:07] <mgz> ah, well that sucks
[10:09] <jfi> wgrant, makes sense, maybe would also be nice that the author of the request has a status to 'abandon' the request
[10:09] <mgz> any deep reason for that, or should we just allow the submitter to reject their own stuff? don't see how it's different from marking it merged
[10:10] <mgz> (in that it could be confusing if set incorrectly, but is otherwise harmless)
[10:55] <mgz> heh:
[10:55] <mgz> # Non reviewers cannot reject proposals [XXX: what about their own?]
[11:02] <jelmer> mgz: they can delete their own, but they can't reject their own merge proposals
[11:03] <mgz> right, that is silly. what's the equivalent of branch.isPersonTrustedReviewer like isPersonOwner or something? there's an owner attribute but that can be a team
[11:03] <mgz> get the owner, then use some person thing to see if user is member?
[11:48] <mgz> okay, this seems to work
[11:49] <mgz> slightly annoying to test with launchpad.dev as you need to leave a bunch of teams first as ~name16 login?
[11:52] <mgz> merged is a bit of a wrinkle, it assumes the person listed as reviewer approved
[11:53] <mgz> so needs review -> rejected -> merged doesn't end up in a correct end state
[11:54] <wgrant> name16 is an admin, so trying to check unprivileged operations with it seems odd :)
[11:54] <wgrant> no-priv might be more appropriate
[11:54] <wgrant> Or name12
[11:57] <mgz> it's not documented on the wiki how to login in as anyone else...
[11:57] <wgrant> I removed passwords in January, so you just need to check another user's email address and use that
[11:58] <mgz> aha.
[11:58] <wgrant> no-priv is usually a good one to start with
[11:58] <mgz> it would be nice if the sample data was a bit more explanitory about what it is testing
[11:59] <wgrant> 2005
[11:59] <mgz> rather than having to learn name16 means adminny things, no-privs is at least sensible (but owns no branches)
[11:59] <wgrant> You might be able to guess how name16 came about
[12:01] <mgz> hm, not sure I have a good one. 16th user in lp db was launchpd dev, and their account was initially used in testing data, then stripped of personal details?
[12:01] <wgrant> name16 is person 16
[12:01] <wgrant> Originally, people didn't have names
[12:02] <wgrant> They were added, and the migration set them all to name$id
[12:02] <wgrant> Tests needed updating
[12:02] <wgrant> So they then became impossible to change without changing dozens, or now hundreds, of tests
[12:02] <wgrant> This is why sample data is bad
[12:03] <wgrant> Sasmple data for tests, that is
[12:03] <mgz> ho ho ho. and why the 16 exactly?
[12:03] <wgrant> That was just the value of the sequence at the time it was created back in 2004 or 2005
[12:03] <wgrant> It should still have person.id == 16
[12:03]  * wgrant checks
[12:04] <wgrant> yeah
[12:08]  * mgz answers own question before asking: `make newsampledata`
[12:12] <mgz> hm, but that didn't actually reset the data which is what I was after...
[12:13] <wgrant> 'make schema' recreates your databases from the tree
[12:13] <wgrant> 'make newsampledata' recreates the sampledata SQL in the tree from your databases
[12:13] <wgrant> (launchpad_dev -> current-dev.sql, launchpad_ftest_playground -> current.sql)
[12:13] <mgz> >_<
[12:13] <mgz> okay, so I need to revert then run the command in the right direction :)
[12:14] <mgz> thanks wgrant
[13:31] <q4a> hi all) I'm trying to update package zathura to new version and upload to my ppa. https://launchpad.net/ubuntu/+source/zathura - here i took debian folder, edit changes, but when I run 'debuild -S -sa', I got: "dpkg-source: info: local changes detected, the modified files are:  zathura-0.2.1/pdf-poppler-0-2-1/AUTHORS"
[13:32] <jelmer> hi q4a
[13:32] <jelmer> q4a: you might want to ask in #ubuntu-packaging, that's not really specific to Launchpad
[13:33] <q4a> jelmer: ok, thx =)
[14:41] <issyl0> 1
[14:41] <issyl0> Oops.
[14:43] <hramrach> hello
[14:43] <hramrach> how do you remove a project from launchpad?
[15:42] <cjohnston> czajkowski: ping
[15:43] <mgz> is on holiday, what do you need cjohnston?
[15:44] <cjohnston> mgz: thanks../52
[15:44] <cjohnston> mgz: I'm looking at bug #1035661 and it's still effecting me
[15:45] <cjohnston> I'm wondering if I should report a new bug, or get someone to reopen that one
[15:47] <mgz> cjohnston: the comment by sinzui implies you should file a new bug
[15:47] <cjohnston> thanks mgz
[16:08] <q4a> hi again) is it possible to add my own ppa the ability to build armhf package?
[16:10] <mgz> q4a: no, we don't provide arm builder except for the main archive and employees
[16:11] <q4a> mgz: may be any time soon? or may be i can build it in my chroot and upload it to launchpad?
[16:13] <mgz> yup, you'll want to build locally and upload
[16:14] <q4a> thx
[16:14] <mgz> hm... does that actually work? I think we might not let binary packages through anyway
[16:14] <mgz> you're probably best off asking in #ubuntu or somewhere how you're meant to support arm
[16:19] <cjohnston> mgz: reported..
[16:19] <cjohnston> thanks
[16:20] <mgz> cjohnston: might just want to add a comment to the closed bug mentioning the one you filed.
[16:24] <cjohnston> hrm.. I've gotten 3 timeouts on LP this morning
[18:18] <mgz> how, launchpad soyuz chums, did my dulwich-daily rebuild end up in the juju ppa rather than the bzr one?

[18:19] <mgz> might be related to the fact I screwed up the changelog first time round, then forgot to bump the version, but might now.
[18:19] <mgz> *not
[18:21] <dobey> mgz: my only guess would be a fumbled build request that set the archive to that one instead of the desired one
[18:23] <mgz> ah, a build request also has an option of where it builds into, that doesn't default to what the recipe says?
[18:23]  * mgz looks
[18:23] <mgz> yup, that seems to be it
[18:24] <dobey> it should default to what the recipe says, but i think the first time you build, it defaults to the first one in the list
[18:25] <dobey> after you build once to the correct ppa it should default to that when you use the request build link on the recipe page, at least
[18:26] <mgz> +request-builds just has a alphabetized <select> and no default
[18:27] <mgz> er, not alphabetized, semi-alphabetized
[18:30] <dobey> right
[18:44] <mgz> hm, and from the package importer...
[18:44] <mgz> bzrlib.errors.UnknownErrorFromSmartServer: Server sent an unexpected error: ('error', 'xmlrpclib.Fault', "<Fault -1: 'Unexpected Zope exception: RequestExpired: request expired.'>")


[06:43] <oSoMoN> good morning trainguards! silo 1 is good to publish, but I can’t mark it as such as there is no corresponding line in the spreadsheet
[06:48] <Mirv> oSoMoN: ok, thanks!
[06:53] <Mirv> oSoMoN: ok, core-dev ack needed. maybe ogra_ will be up soon to check the oxide dep bump + new qml dependency (in main) from https://ci-train.ubuntu.com/job/ubuntu-landing-001-2-publish/lastSuccessfulBuild/artifact/webbrowser-app_packaging_changes.diff and say "ack" :)
[07:39] <infinity> ... who keeps rebuilding nuntuim over and over again?
[07:40] <infinity> abeato: queuebot seems to want to blame you?
[07:40] <abeato> infinity, that's me
[07:40] <abeato> infinity, there is some bug that does not let me to build it for powerPC
[07:40] <abeato> compiler crashing
[07:40] <infinity> abeato: So, two things.  1) rebuilding over and over isn't going to fix a toolchain bug.  2) revving the version every time means you're building on 5 arches and wasting CPU cycles to test 1).
[07:41] <abeato> well, I actually found that some times the build result can vary
[07:41] <abeato> anyway, I opened a bug for gccgo
[07:41] <infinity> 7 times in a row might be a hint that they won't vary. :P
[07:42] <abeato> infinity, indeed :p
[07:42] <infinity> And either way, there are ways to retry just that one broken build, rather than rebuilding over and over with fresh source.
[07:42] <abeato> didn't think about the cycles though, sorry
[07:42] <abeato> infinity, ok, good to know
[07:45] <infinity> abeato: What's the bug number for your gccgo bug?
[07:46] <abeato> infinity, bug #1458761
[07:46] <infinity> abeato: Ahh, wrong package.  But I'll dupe it with LP: #1454183
[07:47] <abeato> infinity, great, thanks... maybe the priority should be risen there
[07:49] <cjwatson> abeato: Yeah, in future ask the trainguards please if you don't have access to retry a single build in the PPA (which any member of ~ci-train-ppa-service can do).  Some other architectures (notably arm64) are short of capacity and this sort of behaviour causes problems there.
[07:50] <abeato> cjwatson, thanks, good to know
[07:51] <cjwatson> sil2100: Is there some way we can improve the citrain UI to hint people away from doing this kind of thing?
[07:51] <cjwatson> like, "don't use this button to retry a single-arch failure" or some such
[07:52] <sil2100> cjwatson: I have an almost finished branch that would allow people to retry single failed PPA builds
[07:52] <sil2100> So this might help once people know about that
[07:52] <cjwatson> That sounds good!
[07:53] <cjwatson> I mean, if the whole thing weren't abusing the Launchpad permission model then it'd be right there in the LP UI, but still.
[07:53] <cjwatson> Hopefully with ephemeral PPAs we can give a grant to the ticket owner or whatever.
[08:11] <sil2100> hm, spreadsheet still broken, let me prepare a migration
[08:15] <sil2100> ATTENTION! Spreadsheet being migrated, old spreadsheet is being disabled
[08:19] <sil2100> jibel: will you be able to re-target the trello scripts to the new spreadsheet in a moment?
[08:20] <jibel> sil2100, sure
[08:29] <jibel> sil2100, ^ if it is the same that was here last week it can be published. ToyKeeper did the verification
[08:29] <jibel> sil2100, I flipped the switch the morning but the spreadsheet probably forgot it
[08:29] <jibel> this*
[08:30] <sil2100> Yeah, it reverts since a day, I'll publish in a moment
[08:31] <oSoMoN> ogra_, hey, if you’re around I’d need a core-dev ack for https://ci-train.ubuntu.com/job/ubuntu-landing-001-2-publish/106/artifact/webbrowser-app_packaging_changes.diff , please
[08:32] <sil2100> Looks good to me, but yeah, it's a package in main so we need someone's thumbs up
[08:35] <sil2100> jibel: new spreadsheet link: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Ahfru_NNQUKMdEZzQ3VHV0xHS3RKcERudVljcXQycWc#gid=0
[08:35] <sil2100> Or https://wiki.ubuntu.com/citrain
[08:36] <sil2100> Dashboard retargetted, commitlog scripts retargetted (not working anyway)
[08:36] <sil2100> Now only trello board scripts and queuebot scripts remain
[08:36] <sil2100> For queuebot I need either stgraber or robru
[08:41] <jibel> sil2100, bot updated
[08:41] <robru> sil2100: nope only stgraber can update qbot (I'm but here either)
[08:43] <sil2100> robru: ah ha!
[08:43] <sil2100> robru: ok, thanks (even though you're not here)
[08:43] <sil2100> jibel: thanks
[08:45] <jibel> pstolowski, Hey, is there a silo with a fix for bug 1457698?
[08:49] <pstolowski> jibel, not yet, i've just requested it in line #66 of the sheet
[08:55] <sil2100> Ah, my first official dual landing!
[08:55] <sil2100> Let's give robru's code a spin :)
[08:58] <ogra_> oSoMoN, lovely ! full ACK :)
[08:58] <sil2100> ogra_: o/
[08:58] <sil2100> Ok, let me publish all those silos now since I'm done with migration
[09:01] <sil2100> ogra_: sorry to bother, but could you take a look at one more quickie? https://ci-train.ubuntu.com/job/ubuntu-landing-019-2-publish/lastSuccessfulBuild/artifact/ubuntu-ui-toolkit_packaging_changes.diff
[09:01] <sil2100> ogra_: looks good as well, it's Mirv's work so it has to ;)
[09:02] <ogra_> sil2100, ACK
[09:02] <sil2100> Thanks again :)
[09:03] <oSoMoN> ogra_, thanks :)
[09:03] <jibel> davmor2, I'm assigned silo 28 to you, you're the only one with a giffgaff SIM
[09:06] <Mirv> ;)
[10:52]  * Mirv away
[10:57] <pstolowski> jibel, hey, the fix you asked about earlier is in silo 15 and tested by me
[11:02] <jibel> pstolowski, thanks. We'll do the verification asap.
[11:07]  * ogra_ wonders why his terminal app doesnt start on arale anymore after it was stated once
[11:07] <ogra_> *started once
[11:08] <ogra_> aha
[11:08] <ogra_> killing the hanging /usr/lib/arm-linux-gnueabihf/ubuntu-app-launch/cgroup-reap-all process makes it work again
[11:08] <ogra_> tedg, ^^^^
[11:09] <ogra_> hmm ... and i can reproduce
[11:11] <sil2100> uh
[11:12] <ogra_> i'll not reboot til tedg shows up
[11:13] <ogra_> quite some regressions in imae 15 vs 14 on arale, i wonder why
[11:13] <ogra_> *image
[11:14] <ogra_> (backlight not turning off when pressing power is another one)
[11:17] <ogra_> and indeed image 15 had powerd changes ... http://people.canonical.com/~ogra/touch-image-stats/vivid/20150525.changes
[11:22] <jamesh> cihelp: ping.  I made a request to the CI list asking for the jobs for the thumbnailer jobs to be reconfigured to point at wily last week.  Has there been any progress on that?
[11:48]  * sil2100 needs to go for lunch
[12:09] <ogra_> sil2100, are you aware that the last three wily image builds failed ?
[12:15] <ogra_> ... fix uploaded
[13:03] <jgdx> hm
[13:08] <boiko> trainguards: I am trying to mark vivid silo 6 as tested but the spreadsheet is giving me server errors
[13:09] <ogra_> are you using the right one ?
[13:09] <ogra_> afaik they switched to a new one again
[13:09] <boiko> now that I looked at the title, seems no :)
[13:09] <boiko> ogra_: thanks
[13:12] <jibel> trainguards, can you publish silo 15?
[13:13] <josepht> jamesh: Yes, I'm in the process of getting the changes made.  Sorry for failing to reply to your email.
[13:26] <jgdx> kenvandine, any idea why I can't rebuild silo 13? ( error msg at http://people.canonical.com/~platform/citrain_dashboard/#?q=ubuntu%2Flanding-013 )
[13:27] <kenvandine> ugh
[13:27] <kenvandine> jgdx, 1) you shouldn't be working
[13:27] <kenvandine> 2) no freaking clue...
[13:27] <kenvandine> i'll look at it though
[13:28] <jgdx> kenvandine, I need to be more precise wrt email subjects/you need to read the email date :P
[13:28] <kenvandine> oh!
[13:28] <kenvandine> haha
[13:28] <kenvandine> yesterday was a holiday for me too :)
[13:28] <kenvandine> i just read your mail 2 minutes ago :)
[13:29] <kenvandine> jgdx, why are you trying to rebuild lxc-android-config?
[13:29] <kenvandine> i merged the changes that landed in it friday
[13:29] <jgdx> kenvandine, I didn't at first, but after I got that error message I did
[13:29] <jgdx> (… try to build lxc config pkg)
[13:30] <kenvandine> ok, you shouldn't need to rebuild that package
[13:30] <kenvandine> oh... i know why
[13:30] <kenvandine> you can only do watch only builds for that one
[13:30] <kenvandine> since i dput it
[13:31] <jgdx> kenvandine, okay, I have no idea what that means
[13:31] <kenvandine> haha
[13:31] <kenvandine> it's not built from a bzr branch
[13:31] <kenvandine> so i uploaded the package to the ppa manually and did a watch only build for it
[13:32] <kenvandine> so when you rebuild settings in that silo, be sure to always specify just that package name to rebuild
[13:32] <kenvandine> or it'll blow chunks :)
[13:41] <mandel> sil2100, one question, if I have a silo that will land stuff in trunk and the same stuff needs to be in vivid, a simple sync works, right? Or do I need to create mrs against a diff series
[13:41] <mandel> ??
[13:41] <ogra_> you should be able to use the new dual silos
[13:41] <ogra_> (see mail)
[13:42] <mandel> ogra_, oh, I probably missed that email, on the the list?
[13:43] <ogra_> yeah
[13:43] <mandel> ack
[13:44]  * mandel reads
[13:47] <pstolowski> thostr_, ^ landing in progress it seems
[13:47] <Mirv> jibel: ok.
[13:57] <sil2100> mandel: yeah, as ogra_ said ;)
[13:58] <sil2100> mandel: robru finished the dual-landing feature
[13:59] <ogra_> sil2100, new livecd-rootfs landed ... feel free to try a new wily image if you want one ... should build now
[14:07] <kgunn> sil2100: so, excuses shows nothing holding up mir....but it says still "stuck in proposed"....does someone need to do something extra ?
[14:09] <ogra_> kgunn, new binary names ? (do youhave any packages that have the version in their package name ?)
[14:09] <ogra_> (libs are typically a good candidate)
[14:09] <camako> sil2100, kgunn, Mir 0.13.1 was having problems landing on Fri due to UITK autopkg test failure which now landed (silo 1). Does it need to be prodded somehow?
[14:10] <kgunn> ogra_: yes, the one in silo 30 has a new versions
[14:10] <kgunn> in the name
[14:10] <ogra_> kgunn, then you need to talk to an archive admin to approve it (in #ubuntu--remease)
[14:11] <ogra_> *release
[14:11] <kgunn> :)
[14:20] <cjwatson> ogra_: New binary names affect entry into -proposed, not migration from -proposed to release.
[14:20] <ogra_> oops, indeed
[14:20] <kgunn> ...and i got distracted anyway
[14:20] <kgunn> so what do i need to do now ?
[14:21] <cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt shows http://paste.ubuntu.com/11371646/
[14:21] <cjwatson> So some of those packages are rendered uninstallable by the upgrade
[14:22] <cjwatson> You need to investigate that
[14:22] <cjwatson> kgunn: It basically looks like qtubuntu-android needs to be rebuilt against the new mir
[14:22] <cjwatson> kgunn: Er, qtubuntu-gles
[14:23] <cjwatson> kgunn: Also qtubuntu
[14:23] <cjwatson> The rest is fallout from that
[14:23] <kgunn> camako: ^
[14:24] <kgunn> cjwatson: one question, we originally landed in vivid+overlay, does it not have the same test ?
[14:24] <cjwatson> it doesn't
[14:24] <kgunn> mmm
[14:24] <kgunn> ...once again, am scared by overlay setup
[14:24] <cjwatson> kgunn: in general, update_excuses is the first stage, and only considers each source package in isolation; the update_output stage considers interaction between packages
[14:24] <cjwatson> there probably ought to be two overlay PPAs, with proposed-migration set up to copy from one to the other
[14:25] <cjwatson> sil2100: ^-
[14:25] <kgunn> cjwatson: what would your recommendation be ?...i can add qtubuntu for this wily landing (which is a sync), and then just go rebuild qtubuntu in overlay ?
[14:26] <cjwatson> kgunn: I don't have a detailed recommendation, something like that sounds roughly reasonable ...
[14:26] <cjwatson> just doing your analysis :)
[14:41] <thostr_> ogra_: do you have more details about powerd issue
[14:41] <ogra_> thostr_, not really, image 14 on aralle was fine, with 15 i see the backlight staying on for ~1min before it shuts off
[14:41] <ogra_> -l
[14:42] <ogra_> thostr_, seems to be reproducable by others ... but it is not easy to see in daylight ...
[14:42] <thostr_> ogra_: when was image 14?
[14:43] <ogra_> dunno, friday or so ...
[14:43] <ogra_> image 15 had these changes: http://people.canonical.com/~ogra/touch-image-stats/vivid/20150525.changes
[14:43] <ogra_> since powerd fiddles with the brightnness settings in that change i think it is a suspicious candidate
[14:44] <charles> ogra_, thanks
[14:44] <charles> ogra_, agreed, it seems the most likely
[14:45] <charles> ogra_, the actual diff looks innocent enough, but the other changes in image 15 look even less like candidates...
[14:45] <ogra_> yeah
[14:45] <ogra_> and the device or custom tarballs didnt change between arale 14 and 15
[14:46] <thostr_> seems there is never ever something like an innocent change....
[14:50] <charles> looks like the latest image on krillin is 14, let's see if that has the behavior...
[14:52] <jgdx> kenvandine, so libsystemsettings1 ubuntu-system-settings in PACKAGES… and what else?
[14:52] <kenvandine> no
[14:52] <kenvandine> just ubuntu-system-settings
[14:52] <kenvandine> it's the source package name
[14:52] <jgdx> okay
[14:52] <kenvandine> that's it
[14:53] <jgdx> thanks
[14:53] <kenvandine> do you need to rebuild again?
[14:53] <kenvandine> i fixed it earlier, just fyi
[14:53] <kenvandine> jgdx, to fix it i did a watch only rebuild, sorted it all out (for future reference)
[14:54] <jgdx> magic, got it
[14:55] <jgdx> kenvandine, yeah, found a bug with the latest hotspot thing using the serverpropsync code
[14:55] <jgdx> fixed and pushed
[14:55] <kenvandine> ok
[15:12] <sil2100_> F**K
[15:12] <sil2100_> Always when I need the internet most, I hate my ISP
[15:12] <sil2100_> ogra_: could you take a look at https://ci-train.ubuntu.com/job/ubuntu-landing-028-2-publish/lastSuccessfulBuild/artifact/network-manager_packaging_changes.diff ?
[15:22] <kgunn> sil2100: sorry about your isp, can you or a delegate hop a quick hangout with me and camako ? to sort this mir stuff out...
[15:22] <sil2100> kgunn: sure, just need some time for my internet to stabilize
[15:28] <sil2100> kgunn: in the meantime, let me take a look at the mir situation
[15:30] <kgunn> sil2100: do you see colin's posts around an hour ago ?
[15:31] <kgunn> regarding...
[15:31] <kgunn> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt shows http://paste.ubuntu.com/11371646/
[15:31] <kgunn>  So some of those packages are rendered uninstallable by the upgrade
[15:31] <kgunn>  You need to investigate that
[15:32] <sil2100> Yeah, I already saw the migration output
[15:33] <sil2100> Sadly we already discussed with slangasek the big issue of not having proposed-migration for the overlay PPA
[15:33] <sil2100> We were thinking of running a separate britney instance just for that purpose, but it's actually a lot of stuff to setup
[15:38] <sil2100> kgunn: anyway, I suppose the only way to unblock is indeed get a silo assigned and rebuild qtubuntu/qtubuntu-gles against the new mir
[15:38] <sil2100> kgunn: you can try getting a dual landing silo for this I suppose
[15:38] <sil2100> It would build binaries for both vivid and wily, since both need fixing
[15:39] <cjwatson> sil2100: Really?  I did most of the prep work to make that kind of thing pretty straightforward before I left Foundations.
[15:39] <kgunn> sil2100: actually....would we need to rebuild everything ? mir+ all it's rdeps
[15:39] <cjwatson> kgunn: Why would you need to rebuild everything?
[15:39] <kgunn> e.g. wouldn't we need to back out that 13.0 from proposed since it's broken?
[15:39] <cjwatson> Er, no
[15:39] <cjwatson> You're fixing it
[15:39] <cjwatson> Backing it out and putting it back in again is a waste of everyone's time
[15:40] <kgunn> ok, my confusion, i thot possibly there might be an issue with the silo
[15:40] <cjwatson> It's already out of the silo
[15:40] <kgunn> happy to just add qtubuntu
[15:40] <sil2100> kgunn: could you prepare a new landing request that only has qtubuntu and qtubuntu-gles? I'll make sure the PPA will build against -proposed
[15:40] <kgunn> cjwatson: ok, so it just sits in proposed and waits until you fix it?
[15:41] <kgunn> camako: ^
[15:41] <cjwatson> kgunn: Well, not me, but yes
[15:41] <kgunn> cjwatson: sure, you=me
[15:41] <sil2100> Yeah
[15:41] <sil2100> That's why we run most tests on -proposed, as this is the place where things can get a bit broken and wait for repair
[15:42] <camako> kgunn, I think alan_g is doing the mir 0.13.0 landing
[15:43] <alan_g> camako: I thought it was done?
[15:43] <cjwatson> sil2100: It would require tweaking archive-reports to mirror the PPA(s), the britney1 wrapper scripts to assemble Packages files from the appropriate mirror, either coming up with some way to run autopkgtests/boottests or disabling them in the interim, and teaching promote-to-release to copy between PPAs
[15:43] <cjwatson> I think that's about it
[15:43] <camako> alan_g, me too
[15:43] <cjwatson> sil2100: autopkgtests/boottests are potentially complicated, indeed, but bearing in mind that they aren't being run for the vivid overlay right now, it would still be an improvement to run the rest of proposed-migration with those disabled
[15:44] <cjwatson> Should be under a day's work all told if you omit the test runner bits
[15:45] <sil2100> hmmm
[15:45] <alan_g> camako: so what do you think I'm doing?
[15:46] <sil2100> cjwatson: that's good news then, since from what I talked with slangasek it seemed a bit troublesome to setup, requiring some input from CI - but maybe that was because of the boottests
[15:46] <kgunn> alan_g: long story short, there's some package interaction
[15:46] <kgunn> testing that's only done in the official archive
[15:46] <kgunn> not currently in vivid+ovly
[15:46] <cjwatson> sil2100: the CI input would be for autopkgtests/boottests
[15:46] <camako> alan_g, mir 0.13.0 failed to land on wily is the bottom line
[15:47] <cjwatson> sil2100: I agree that starts to get into things that are less than trivial, but as I say, it's surely better to have proposed-migration with no test runners than no p-m at all
[15:47] <kgunn> alan_g: so it seems that it caught the need for us to rebuild qtubuntu/qtubuntu-gles
[15:47] <sil2100> alan_g: it looks like qtubuntu/qtubuntu-gles will have to be rebuilt with the latest mir
[15:47] <sil2100> alan_g: I would propose preparing a new silo using the dual-landing functionality
[15:47] <sil2100> This would also unblock mir wily migration
[15:47] <kgunn> right ^
[15:47] <kgunn> broken in both
[15:57] <alan_g> cjwatson: I'm playing catchup here. What problem are you having with qtubuntu?
[15:57] <sil2100> alan_g: it seems to be causing trouble causing uninstallable packages with the new mir in -proposed
[15:59] <alan_g> Do we know why it is "uninstallable" or do I need to reproduce that?
[15:59] <cjwatson> alan_g: *I'm* not having any problem personally; I'm helping kgunn out with analysis.  qtubuntu has not been rebuilt against the new libmircommon ABI and needs to be.
[15:59] <cjwatson> alan_g: You don't need to reproduce anything, it's trivially uninstallable per its dependencies.
[16:00] <cjwatson> alan_g: Or rather would be once the old libmircommon is removed.  Detecting this kind of problem is one of the core functions of the proposed-migration system.
[16:00] <alan_g> cjwatson: that's odd, libmircommon ought to be ABI compatible.
[16:00] <alan_g> Sorry, thinko
[16:00] <cjwatson> libmircommon3                    | 0.12.1+15.04.20150324-0ubuntu1 | wily                   | amd64, arm64, armhf, i386
[16:00] <cjwatson>  libmircommon4                    | 0.13.1+15.10.20150520-0ubuntu1 | wily-proposed          | amd64, arm64, armhf, i386
[16:00] <cjwatson> alan_g: ^-
[16:00] <cjwatson> qtubuntu-desktop etc. still depend on libmircommon3
[16:01] <cjwatson> Therefore they need to be rebuilt
[16:01] <alan_g> Ok. The real problem is that qtubuntu binds to libmircommon at all
[16:01] <cjwatson> How you fix it is up to you
[16:01] <cjwatson> But mir ain't getting through -proposed until it doesn't increase the uninstallable count :-)
[16:01] <alan_g> Sure. Just trying to understand the difficulty
[16:03] <alan_g> kgunn: did you say we have a silo?
[16:06] <kgunn> alan_g: no, we don't have a silo atm
[16:06] <kgunn> to correct this
[16:06] <kgunn> alan_g:  and...looks like what i was thinking, we have a dep we shouldn't
[16:09] <sil2100> I can give you guys a silo if anything, we have plenty
[16:09] <alan_g> kgunn: it's a guess, but I know libmirclient (prior to 13) had a public transitive dependency on libmircommon and (I think) some entry points were in the wrong library at some point prior to 012. I suspect that the dependency comes from that.
[16:11] <alan_g> sil2100: I'm in my last hour of the day, but if you won't run out...
[16:13] <pmcgowan> jibel, fyi the last tarball had the wifi wakeup workaround from alex
[17:10] <robru> sil2100: hey how'd it go today?
[17:12] <robru> been a long time since I did a cu2d rollout ;-)
[17:13] <cwayne> fginther, ping
[17:15] <cwayne> cihelp pingerino
[17:17] <sil2100> cwayne: give me a ping-back if you have everything setup for the arale customs :)
[17:17] <sil2100> robru: nothing exploded so far!
[17:17] <robru> sweet
[17:17] <sil2100> robru: let me check the status of one of the landings, one moment
[17:18] <sil2100> robru: ah, btw. we migrated the spreadsheet, so I changed the dashboard locally on platform but didn't commit to your git repo :)
[17:18] <plars> cwayne: did you need something?
[17:18] <cwayne> sil2100, will do, having a quick hiccup with jenkins not wanting to build customs though..
[17:18] <cwayne> plars, yeah, trying to figure out what's up with this: http://s-jenkins.ubuntu-ci:8080/view/cambridge/job/Arale%20Custom%20Tarball/21/console
[17:19] <cwayne> i.e., jenkins not being able to branch stuff from hanloon (that worked yesterday)
[17:19] <sil2100> robru: so, the silo looks goodish, although it seems something funny happened to the wily upload
[17:19] <sil2100> robru: not sure if that's caused by anything CI Train doing
[17:19] <plars> cwayne: I've been getting that on some branches here too, I think something is wrong with launchpad right now :(
[17:20] <robru> sil2100: what looks goofy?
[17:23] <robru> sil2100: oh did you get queuebot updated with stgraber?
[17:23] <sil2100> robru: so it seems it published it to -proposed correctlish but the train can't track it
[17:23] <sil2100> robru: not yet, will poke him soon
[17:24] <sil2100> robru: anyway, take a look at silo 15
[17:24] <sil2100> It's a dual-landing one
[17:24] <sil2100> The package is in vivid-overlay and wily, but it cannot find it anywhere it seems
[17:25] <robru> sil2100: is that the only dual silo that's been published? or have others been successful?
[17:25] <sil2100> I don't remember if we had any others, since basically dual-landings will be low on usage currently due to the vivid landing gates closed - so we only accept selected fixes
[17:25] <robru> sil2100: that's really weird, the primary mp-based build I didn't change any codepaths. I just added some hooks to also do vivid stuff on top of all the existing wily code that was already going
[17:26] <sil2100> Not sure if Mirv had published anything besides this one
[17:26] <cwayne> sil2100, so jenkins+lp is being a bit finnicky, but the jobs themselves are created
[17:27] <cwayne> sil2100, http://s-jenkins.ubuntu-ci:8080/view/cambridge/job/Arale%20Custom%20Tarball/lastSuccessfulBuild/artifact/out/bq-international/build/custom.tar.xz would be the meizu.en-proposed
[17:27] <cwayne> and http://s-jenkins.ubuntu-ci:8080/view/cambridge/job/Arale%20Tarball%20Vivid%20-%20Gated/lastSuccessfulBuild/artifact/custom.tar.xz would be meizu.en
[17:27] <sil2100> ACK
[17:27] <sil2100> Thanks :)
[17:27] <robru> sil2100: uh I can't branch any lp branches it seems. great
[17:30] <robru> cjwatson: hey, uh.... http://paste.ubuntu.com/11374362/ how would I troubleshoot this?
[17:31] <robru> cjwatson: happening on public branches and 'bzr whoami' and 'bzr lp-login' have sensible values...
[17:40] <boiko> trainguards: can I have a silo assigned again for row 24?
[17:41] <robru> boiko: sure one sec
[17:41] <robru> boiko: are you wanting to land in JUST wily or do you want wily + vivid in one go?
[17:42] <boiko> robru: that's a good question actually, bfiller ^
[17:43] <bfiller> boiko: which silo?
[17:43] <boiko> bfiller: address-book splitting
[17:44] <bfiller> boiko: vivid overlay is frozen now for ota-4, so if we want to land that it will have to be wily only for now.
[17:44] <boiko> robru: so wily only :)
[17:44] <boiko> bfiller: thanks
[17:44] <robru> bfiller: sil2100: i wonder though will it be ready to land before vivid unfreezes?
[17:44] <bfiller> boiko: don't know if I'd bother retargetting until we at least get it working first?
[17:45] <boiko> bfiller: well, for two of the problems QA found I already fixed, there is only one or two left
[17:45] <boiko> bfiller: but yeah, maybe we can start testing it using vivid
[17:45] <bfiller> boiko: I would
[17:45] <boiko> robru: so, let me change it to vivid only
[17:45] <bfiller> boiko: after fully working and ready to land lets see where to land it
[17:46] <boiko> bfiller: yep, makes sense
[17:46] <robru> bfiller: well the issue is that you can't just go back and change it; the packages would need to be rebuilt if you were going to change from vivid to wily or wily to vivid.
[17:46] <bfiller> robru: understand
[17:46] <robru> bfiller: we could set it for both and then you have the option to delete the vivid packages later if you want to land in wily without them
[17:48] <bfiller> robru: ok
[17:48] <robru> bfiller: ok so I'll assign for both then?
[17:48] <bfiller> robru: yes please
[17:49] <robru> bfiller: oh, lp is broken
[17:49] <robru> bah
[17:52] <robru> bfiller: ok, got you silo 16.
[17:56] <robru> boiko: bfiller: so trigger the build normally in 16 and you'll see both vivid and wily packages in the silo. when you're ready to publish you can choose whether you want to publish just one or both (will need a trainguard to delete the unwanted packages and reconfigure silo)
[17:56] <bfiller> robru: ok thanks, boiko ^^^
[17:57] <boiko> robru: nice! thanks!
[17:57] <robru> you're welcome!
[17:58] <sil2100> robru: anyway, besides the migration check, everything works like a charm it seems
[17:59] <robru> sil2100: well, with the migration check not working, auto-merge-clean is also broken ;-)
[18:00] <sil2100> robru: hah, right, although everyone had their share of manual merge-and-cleaning in the past already, so we can live with it until it's not fixed ;)
[18:00] <sil2100> s/not fixed/fixed
[18:00] <robru> sil2100: just looking over the code, I'm not sure why it wouldn't work... this is a bit curious.
[18:02] <robru> sil2100: nm, I figured it out. .project file gets clobbered with vivid version number, so migration phase is expecting wily to have vivid version
[18:03] <sil2100> Ah, right, double build and the vivid one is second
[18:09] <robru> sil2100: ok should have a fix soon, just testing.
[18:25] <cjwatson> robru: Sorted by a rollback, I believe, but I'm still trying to figure out how this makes any sense
[18:26] <robru> cjwatson: yes it seems to be working now, thanks for that.
[18:27] <cjwatson> robru: Well, I was at dinner, sysadmin handled the rollback :)
[18:28] <robru> cjwatson: heh. do you need a guinea pig to test on?
[18:30] <cjwatson> no
[18:38] <charles> trainguards, can I get a silo for line 67 for https://bugs.launchpad.net/powerd/+bug/1458936
[18:39] <robru> charles: ah, a dual landing, excellent choice ;-)
[18:39] <sil2100> ;)
[18:39] <sil2100> robru: \o/
[18:39] <robru> charles: silo 19
[18:39]  * charles hides
[18:39] <charles> robru, thanks
[18:39] <robru> sil2100: ok I have a fix for migration, with tests. will go live and hope for the best.
[18:40] <robru> charles: you're welcome
[18:40] <sil2100> Right, not much possibility of testing it in staging
[18:40] <robru> sil2100: yeah, but the test coverage is *really* *good* ;-)
[18:40] <robru> sil2100: like 110% coverage.
[18:42] <charles> only 110%?
[18:42] <robru> charles: I know I can only do so much.
[18:42] <sil2100> Wow
[19:17] <robru> sil2100: ok, migration phase looking good
[19:28] <robru> cihelp more boottest hiccups? can somebody retry? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api
[19:28]  * thomi looks
[19:29] <robru> thomi: thanks
[19:30] <thomi> robru: both retried and running now
[19:31] <robru> thomi: thanks!
[20:38] <robru> sil2100: good god are you still around? ^^ silo 15 migrated & merged successfully thanks to my train fix & thomi's help with boottest.
[20:39] <sil2100> \o/
[20:39] <sil2100> That's excellent news, then it means we're ready for post-OTA
[20:40] <sil2100> No more worries about syncing things wily<->vivid!
[20:40] <sil2100> robru: thanks!
[20:41] <jibel> sil2100, I verified silo 19 on arale (powerd fix) and charles did it on krillin, I think you can publish
[20:41] <charles> \o/
[20:41] <sil2100> Another dual landing landing
[20:42] <sil2100> ^ ignore that
[20:42] <charles> heh
[20:42] <sil2100> queuebot got switched to the new spreadsheet
[20:42] <jibel> lol, busy night for QA :)
[20:42] <sil2100> charles, jibel: published, waiting for packages to fully settle and kicking a new rootfs
[20:42] <sil2100> For vivid
[20:43] <awe> sil2100, hey... just noticed that there's a note about reviewing packaging changes in the NM silo ( 28 )?
[20:43] <charles> sil2100, jibel, om26er, thanks for the expedited service
[20:44] <sil2100> awe: argh! Yeah, poked ogra_ about those and didn't get an answer, need that published too
[20:44] <sil2100> awe: on it
[20:44] <awe> k
[20:44] <awe> let me know if you need anything from me
[20:45] <sil2100> No worries
[20:45] <sil2100> Anyway, waiting for both silos and *then* kicking the new image
[20:47] <ToyKeeper> alecu: FWIW, I see anywhere from 1s to 24s of backlight on image 15.
[20:47] <ToyKeeper> ... wrong channel, d'oh.  :)
[20:52] <sil2100> New image build running
[20:52] <sil2100> Going now o/
[20:56] <robru> but but... did he wait for it to show up in rmadison? that seems too fast...
[21:07] <robru> oh, vivid would be copied instantly, nm ;-)
[23:56] <robru> rsalveti: http://people.canonical.com/~platform/citrain_dashboard/#?q=14.09 what's going on here? can I free this? we're sunsetting rtm support in the train


[00:06] <nacc> Pharaoh_Atem: sigh, http://trac.roundcube.net/ticket/1490544
[00:06] <nacc> not packaged yet either, will need to figure that out tmrw
[00:08] <slangasek> nacc: pictor, your patch is against a stale version; there's a 2.35-0ubuntu1 package that you're in the changelog of
[00:08] <nacc> slangasek: ha! ok ... let me check that, sorry
[00:10] <slangasek> nacc: likewise, simplesamlphp is against a stale version
[00:11] <slangasek> nacc: and I would dearly love for further debdiffs to be in a bug per package instead of in one bug report with 800 tasks... at some point LP is going to flip the table on us
[00:12] <nacc> slangasek: ok, i can do that from now on ... sorry
[00:12] <nacc> slangasek: so looks like roundcube 1.2 (current at beta) is teh only version that supports php7 ... similar issue as drupal7, afaict
[00:14] <nacc> kirkland: for the pictor upload (2.35-0ubuntu1) why did you keep php5 compat in the control file? there is no php5-imagick, e.g., in xenial
[00:14] <nacc> kirkland: are you ok if we drop that compat?
[00:18] <slangasek> nacc: my view is that if it's in universe and it doesn't support php7, it's expendable and can be cut from release.  I am not, however, the product manager for Ubuntu Server.  From an archive/release POV, I'm perfectly willing to take a roundcube beta into the release instead, if a) someone is willing to do the work to prepare that package and make it work, b) upstream isn't going to yell at us for
[00:18] <slangasek>  including their beta, c) any requests for an update ...
[00:18] <slangasek> ... from the beta to the final release post-16.04 follow the SRU process
[00:22] <nacc> slangasek: yep, understood. I think there are a class of applications that simply aren't going to be updated; but roundcube is making progress it seems like. I'll take a look at the packaging requirements tmrw
[00:23] <nacc> slangasek: updated simplesamlphp debdiff
[00:23] <nacc> slangasek: pictor may be fine as-is, depends on what kirkland wants to do
[00:24] <slangasek> nacc: the | php5 stuff shouldn't break the package, if there were no changes to the actual contents
[00:27] <nacc> slangasek: it shows up in http://people.canonical.com/~ubuntu-archive/nbs.html
[00:27] <nacc> and i was aksed to fix that
[00:27] <slangasek> nacc: well, when we remove php5 from the archive, it will not show up there anymore ;)
[00:28] <nacc> won't it? the pictor package will still depend on php | php5, php-imagick | php5-imagick ?
[00:28] <slangasek> nacc: this is a limitation of nbs, it doesn't know how to unpick alternative dependencies
[00:28] <nacc> slangasek: ah ok, i wasn't sure, yeah, it's purely an alternative for that one
[00:29] <nacc> the others are real and fixed in today's set of patches
[00:29] <slangasek> if that's the only remaining revdep of php5-imagick, and pictor depends php-imagick | php5-imagick, we can pull it already
[00:29] <nacc> yep, afaict that's it and how it is
[00:30] <slangasek> nacc: php5-imagick removed from xenial
[00:44] <slangasek> doko: python3.5 - why bump libmpdec_version instead of removing this check from the testsuite? why is python hard-coding a requirement of a matching minor version of libmpdec?
[00:51] <nacc> slangasek: thanks!
[01:36] <slangasek> nacc: should simplesamlphp's bin/memcacheSync.php have been updated?
[02:57] <karstensrage> hi
[02:57] <karstensrage> how does something from debian packaging get into ubuntu
[02:57] <karstensrage> for example if a debian package is new
[02:58] <karstensrage> how would it get into 14.04?
[03:02] <infinity> karstensrage: You wouldn't, 14.04 is a stable release.
[03:02] <infinity> karstensrage: But we can get it into 16.04
[03:03] <infinity> (And then you could perhaps request a backport)
[03:04] <karstensrage> how do i do that
[03:04] <karstensrage> has 16.04 synced to debian yet?
[03:06] <infinity> karstensrage: I don't know what package you're asking about...
[03:10] <karstensrage> can i pm?
[03:11] <infinity> Public conversations work fine.
[03:11] <Unit193> Because of your asking, I requested a sync. :3
[03:12]  * Unit193 waits for the day infinity kills him. :D
[03:17] <karstensrage> infinity, https://packages.debian.org/testing/libs/libufpidentity1
[03:17] <karstensrage> there is another one coming too, but its stuck in mentors
[03:18] <karstensrage> hi Unit193
[03:19] <infinity> karstensrage: Synced to 16.04
[03:19] <karstensrage> it is?
[03:19] <infinity> karstensrage: When the mentors one clears Debian NEW, let me know and I'll grab that too.
[03:19] <karstensrage> alright? can i see that?
[03:19] <karstensrage> and how do i ask for a backport for 14.04?
[03:20] <karstensrage> thank you so much
[03:20] <infinity> https://launchpad.net/ubuntu/+source/identity4c/1.0-1
[03:20] <infinity> karstensrage: To request backports, you need to talk to the backports folks.
[03:21] <infinity> karstensrage: https://wiki.ubuntu.com/UbuntuBackports
[03:22] <karstensrage> ok thank you
[03:29] <karstensrage> infinity, how long do i have for clearing Debian New
[03:29] <infinity> karstensrage: Well, we release 16.04 in under a month.  So, that long.
[03:29] <karstensrage> hmmm
[03:30] <karstensrage> ill do my best
[03:42] <karstensrage> oh infinity did that pull in the devel package too?
[03:42] <karstensrage> dev package?
[03:44] <karstensrage> oh yes
[03:44] <karstensrage> i see thank you
[03:56] <karstensrage> whats a good candidate for the reasoning part?
[03:56] <karstensrage> just want new functionality on 14.04?
[03:56] <karstensrage> and possibly 12.04 since there are still machines out there that havent updated?
[05:25] <ilhami> hey
[05:25] <ilhami> Has OTA 10 been released yet by Canonical?
[06:14] <slangasek> nacc: so, the simplesamlphp diff switches a dep to php-mhash, which doesn't exist?
[06:14] <slangasek> nacc: but neither does php5-mhash
[06:17] <infinity> slangasek: mhash is builtin to all SAPIs (for both 5 and 7.0)
[06:17] <infinity> So that's a useless dep.
[06:19] <slangasek> ok, so it was probably a legacy provides
[09:13] <LocutusOfBorg> hi folks, do you have any news about glibc/binutils/powerpc breakage?
[09:14] <LocutusOfBorg> ginggs, I found your chat, but I didn't see any answer :(
[10:03] <infinity> LocutusOfBorg: What glibc/binutils/powerpc breakage?
[10:04] <LocutusOfBorg> infinity, nobody can install fpc on powerpc
[10:04] <LocutusOfBorg> simple as that
[10:04] <infinity> And this is glibc's fault somehow?
[10:04] <LocutusOfBorg> ginggs, did some debugging
[10:04] <LocutusOfBorg> the postinst script has a command that triggers a SEGFAULT
[10:05] <LocutusOfBorg> and downgrading glibc fixes the issue
[10:05] <LocutusOfBorg> let me find the bits, just a second
[10:05] <LocutusOfBorg> [17:20:25] <ginggs> doko, infinity, LocutusOfBorg: I've confirmed the
[10:05] <LocutusOfBorg> problem with installing fpc 3 on powerpc is related to glibc 2.23.
[10:05] <LocutusOfBorg> After downgrading  libc6*, gcc* and locales, fp-compiler installs just
[10:05] <LocutusOfBorg> fine. Any ideas?
[10:06] <LocutusOfBorg> "I get the same access violation just running 'fpcmkcfg-3.0.0'.
[10:06] <LocutusOfBorg> And even just asking for help segfaults."
[10:06] <infinity> Hrm.  No ideas, but I can look into it later.
[10:07] <LocutusOfBorg> you can just call that "fpcmkcfg-3.0.0 -h" command
[10:07] <infinity> Right.  I'll give it a stab later.  It's almost certainly fpc's fault, not glibc's, but I'll need to dig and sort out why to prove that theory. :P
[10:07] <LocutusOfBorg> the problem is: fpc doesn't build on powerpc anymore because it depends on itself
[10:07] <Unit193> zigo: python-googleapi has a few incompatibilities with the python-oauth2client now in xenial.
[10:07] <infinity> (And it needs fixing either way)
[10:08] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/fpc
[10:08] <zigo> Unit193: Oh... :/
[10:08] <infinity> LocutusOfBorg: Yeah, I know, I have the build log open.
[10:08] <LocutusOfBorg> thanks!
[10:08] <infinity> LocutusOfBorg: Like I said, I'll look later.
[10:08] <Unit193> zigo: New upstream fixes it at least..
[10:08] <infinity> LocutusOfBorg: I'd like to understand why it broke before I just go and rebootstrap it.
[10:08] <LocutusOfBorg> I'm happy to fix fpc sure, but I think I won't be able to do it alone, right?
[10:08] <infinity> Cause if it's using internal symbols or something, it should stop.
[10:08] <LocutusOfBorg> thanks a lot, funny enough it was working with the older glibc :)
[10:08] <LocutusOfBorg> thanks for giving a shot!
[10:09] <ginggs> infinity: thanks. FWIW with the new glibc, I was able to install fpc 2.6.4 from wily but building 3.0.0 failed with the same access violation at 99% :(
[10:09] <zigo> Unit193: I'm not the maintainer of it, so maybe you could ping Laszlo Boszormenyi, he's usually very responsive.
[10:09] <zigo> (and maintains a lot of stuff there...)
[10:09] <LocutusOfBorg> that fpc has important fPIC fixes on arm* I need them, because they are a big regression compared with 2.6.4, and fixes hedgewars
[10:09] <Unit193> Unfortunately and more importantly to me, broke gcalcli too. ;/
[10:10] <infinity> LocutusOfBorg: Ahh, well, wouldn't want hedgewars to be broken. ;)
[10:10] <LocutusOfBorg> yeah, nothing is more imporant in life than games :)
[10:10] <infinity> LocutusOfBorg: I'm about to take a long weekend, but I might poke fpc when bored.
[10:10] <infinity> I vaguely recall the last time I rummaged around in fpc's guts.
[10:10] <LocutusOfBorg> thanks! and happy Easter, I'll be taking a rest too :)
[10:11] <LocutusOfBorg> s/rest/helpwifeincookingalotofstuffforeaster/
[12:30] <mterry> doko: no they aren't stuck anymore, thanks
[12:42] <Laney> Anyone know where I can find langpack generation logs?
[12:42] <Laney> or another way that I can get a list of packages that have their translations put in there
[12:50] <Laney> aha I found mapping.txt
[14:05] <superm1> infinity: since beta2 is out no concerns from me in unblocking that mysql-5.7 out of proposed
[14:05] <superm1> i can sort out fallout in the myth* stuff now
[14:20] <Skuggen> superm1: Nice. We also need to fix some test failures with dbconfig-common for it (and redmine, but I'm guessing those can also be traced to dbconfig)
[14:30] <ginggs> doko: julia has been FTBFS on armhf for several weeks, I've just tried downgrading to gcc-5 5.3.1-3ubuntu1 (where I know I definitely built before) and it builds fine. What can I do further?
[14:31] <hikiko> infinity, slangasek ping
[14:32] <hikiko> Program received signal SIGPIPE, Broken pipe.
[14:32] <hikiko> 0x00007f82e0535417 in __libc_writev (fd=50, vector=
[14:32] <hikiko>     at ../sysdeps/unix/sysv/linux/writev.c:49
[14:32] <hikiko> the x crash
[14:33] <hikiko> compiz didn't crash it crashes later because of x
[14:33] <superm1> Skuggen: http://paste.ubuntu.com/15496370/
[14:33] <superm1> Skuggen: that's with the stuff in proposed, not sure where that header is supposed to be coming from
[14:34] <Skuggen> Hm. Could you check what's in include/mysql/mysql? There's some mess with the header layout the devs haven't gotten around to clean up yet (though I don't think it should have been moved)
[14:34] <hikiko> sorry :)
[14:35] <hikiko> wrong signal
[14:35] <hikiko> that's earlier :p
[14:35] <superm1> Skuggen: looks to be in that directory
[14:35] <superm1> http://paste.ubuntu.com/15496401/
[14:37] <Skuggen> superm1: But it used to work in 5.6? From what I can see in the source the file is in the same place for 5.6.28
[14:37] <superm1> Skuggen: never caused build failures previously
[14:37] <superm1> so maybe the path declared in /usr/include/mysql/mysql/client_plugin.h changed?
[14:42] <superm1> Skuggen: from what i see in 5.5 (on 14.04 box) client_plugin.h wasn't included in /usr/include/mysql/mysql.h, so that's the part that's newer
[14:42] <superm1> don't have a 5.6 handy ATM
[14:43] <Skuggen> Ah, no it's not included in 5.6
[14:44] <Skuggen> https://github.com/ltangvald/mysql-5.6/blob/master/include/mysql.h
[14:46] <Skuggen> If you add include/mysql on the include path, does it work?
[14:47] <superm1> yes that works
[14:48] <superm1> the part that broke for me was this is how a configure script was testing things
[14:51] <Skuggen> Yeah, it's kind of a mess the way the includes are structured right now :|
[15:10] <nacc> slangasek: ah sorry, thanks for catching that!
[15:14] <nacc> slangasek: we can probably do a best effort here, if you're ok with an addition fix for simplesamlphp to suggest `phpenmod -s cli memcache`, iiuc
[15:14] <nacc> Pharaoh_Atem: --^ is that rigth?
[15:27] <nacc> Pharaoh_Atem: and independently, how well do you know horde? :)
[15:28] <nacc> Pharaoh_Atem: nm on the latter
[16:17] <barry> slangasek: i think we should ignore pbgenomicconsensus amd64.  retries don't help but local adt-runs in xenial-proposed chroots always pass for me
[16:17] <barry> slangasek: then there's python-pbh5tools; pretty much same deal
[16:30] <nacc> slangasek: re: LP: 1562060, i tested that the roundcube 1.2~beta installs and seems to run (I don't have an IMAP server setup so can't test it further)
[16:49] <karstensrage> infinity, how come it looks everything has been published but when i search for the package here https://launchpad.net/ubuntu/xenial it doesnt show up?
[16:50] <karstensrage> infinity, also do i have to woo some sponsor for a backport bug or are they just picked up eventually?
[17:21] <nacc> karstensrage: hrm? https://launchpad.net/ubuntu/xenial/+search?text=libufpidentity1
[17:23] <nacc> slangasek: fyi, I think with LP: #1562090 just filed, the horde stuff stuck in proposed should pass its tests
[17:23] <nacc> i'll keep working through the rest of horde
[17:34] <Pharaoh_Atem> nacc: on the former, that looks right to me
[17:34] <nacc> Pharaoh_Atem: ok, will send a patch, thanks
[17:35] <Pharaoh_Atem> on the latter, I have little clue about Horde :/
[18:54] <jdstrand> cjwatson: fyi (I don't need anything right now), bug #1562118
[20:15] <slangasek> hikiko: did you get a full backtrace under gdb of the crash? 'bt full'.  also are you sure it was the SIGPIPE that killed the process, and that X didn't handle that SIGPIPE later?
[20:19] <slangasek> barry: pbgenomicconsensus, you probably can't reproduce the failure because you're testing with different versions of packages than what the autopkgtest infrastructure does.  I'm guessing you're doing a run with -proposed versions of packages, rather than using python-pysam 0.7.7-1ubuntu1 like the log shows?  So, it's possible to skip this test failure for python-setuptools since we know python-set
[20:19] <slangasek> uptools isn't the cause, but please follow up on ...
[20:19] <slangasek> ... python-pysam because this indicates real bugginess currently in xenial
[20:34] <nacc> slangasek: looks like moodle is similar to drupal and others ... working on it now, had to fix the watch file too :/
[21:07] <slangasek> barry: there, pbgenomicconsensus no longer a failed test ;)
[21:07] <slangasek> nacc: hehe, enjoy...
[21:08] <slangasek> nacc: LP: #1562090 uploaded, which horde tests do we want retried once that's published?
[21:09] <nacc> slangasek: sorry, we'll need that one and the others i submitted today, wnat me to give you the list? I think i subscribed you to all of htem?
[21:09] <nacc> turba is the big one, it seems like (affecting a bunch of other packages that is)
[21:10] <slangasek> nacc: if you subscribed me then the list is in my inbox.  ok, from your earlier comment I understood that 1562090 was the only one needed for unblocking, but yes I had seen the turba failures and wondered how -passwd was going to unblock that.  I'll have a look, though I'm actually off today so no promises that I'll get through the stack before Monday
[21:10] <nacc> slangasek: it's ok, i just  wanted to let you know they were taken care of :)
[21:11] <nacc> slangasek: i'd rather you didn't work today and relaxed!
[21:13] <slangasek> nacc: I relax better with fewer incoming tasks in my inbox ;-)
[21:14] <nacc> slangasek: uhh, unlikely! although on my last check, we were down to 350 packages! these bigger frameworks slow me down, obviously, as pulling in a new version is not the easiest thing
[21:17] <barry> slangasek: magic!
[21:18] <slangasek> barry: python-pbh5tools still broken though, also points to pysam, so retrying with -proposed pysam there as well.  So maybe this unblocks it without hinting, but then python-pysam still needs attention to get it migrated
[21:20] <barry> slangasek: ack
[22:53] <Umeaboy> Hi!
[22:53] <Umeaboy> I made a bugreport about E173 not being able to connect in Xenial.
[22:53] <Umeaboy> Sorry.
[22:54] <Umeaboy> In Wily.
[22:54] <Umeaboy> It works on Xenial.
[22:54] <Umeaboy> Can someone please push an update of NetworkManager and Policykit from Xenial to Wily?
[22:55] <Umeaboy> The problem is at the window to enter the pin code.
[22:55] <Umeaboy> It just won't accept it even thou it's entirely correct.
[23:45] <cjwatson> jdstrand: yeah, hoping to have time to sort that out pretty soon