[02:01] <psusi> I have noticed some udev attributes like this: ID_MODEL_FROM_DATABASE=P8P67 Deluxe Motherboard.  Where does this come from?  Is there a database somewhere one could record that it is known on such and such model motherboard that ata port X is in fact, esata?
[02:58] <cjwatson> xnox: Could you please merge qutecom for the libav transition?
[05:32] <pitti> Good morning
[06:31] <dholbach> good morning
[08:13] <xnox> cjwatson: ack.
[08:50] <LocutusOfBorg1> Hi ubuntu developers
[08:51] <LocutusOfBorg1> do you think flex should be demoted on universe?
[08:51] <LocutusOfBorg1> https://launchpad.net/ubuntu/+source/flex
[08:51] <LocutusOfBorg1> the last -8 upload needs cm-super, available on universe
[08:52] <LocutusOfBorg1> so there is a FTBFS because of the missing dependency on i386 (B-D-I)
[08:55] <xnox> LocutusOfBorg1: no, we can't demote flex. Because then a good chunk of main will not be able to build anymore.
[08:56] <seb128> LocutusOfBorg1, http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.trusty/rdepends/flex/flex
[08:56] <xnox> LocutusOfBorg1: we'd typically promote cm-super-minimal into main, or modify documentation building process to not require it.
[08:57] <Laney> https://bugs.launchpad.net/ubuntu/+source/cm-super/+bug/1328509
[08:59] <xnox> slangasek: bmurray: can you please subscribe foundations to pfb2t1c2pfb ?
[08:59] <xnox> (ps. not a typo)
[08:59] <Laney> bless you
[08:59] <xnox> should unblock above MIR ^
[09:07] <LocutusOfBorg1> :) yes a MIR is indeed better :)
[09:27] <pitti> xnox: pronounce that 5 times in succession?
[09:28] <xnox> pitti: "that p package's name i have written on the post-it note" http://xkcd.com/1105/
[09:28] <Laney> it's a silly name for a package which contains two conversion tools: pfb2t1c and t1c2pfb
[09:29] <pitti> haha
[09:51] <cjwatson> Riddell: Hm, why the weird merged version for opencv?
[09:53] <menace> Hi, i wanted to testbuild libreoffice on ubuntu. i did apt-get build-dep libreoffice ; apt-get source libreoffice ; i only updated the changelog of the libreoffice file and tried to rebuild it with dpkg-buildpackage -uc -us. But it breaks on trusty with an compilation error (http://pastebin.com/zBd2Fj7p). Since packages should be able to be rebuilt, why does that fail? Any Idea?
[09:57] <infinity> menace: This is fixed in trusty, and will be fixed in utopic in the next upload.
[09:58] <infinity> menace: This diff will fix it for you: http://launchpadlibrarian.net/177856415/libreoffice_1%3A4.2.4-0ubuntu1_1%3A4.2.4-0ubuntu2.diff.gz
[09:59] <Riddell> cjwatson: oh yes, my mistake, do you know I should upload again with the right version number?
[09:59] <cjwatson> Riddell: Not urgent, if you like, was just wondering
[10:41] <TheMuso`> Does anybody know if we are likely to move to kmod version 17 this cycle?
[10:42] <pitti> TheMuso`: we should certainly merge it, particularly if it's blocking you or anyone else
[10:49] <TheMuso`> pitti: Its not blocking me as such, but alsa bits in Debian are starting to depend on it, and keeping in sync would be easier if we were in lock step with kmod.
[11:24] <menace> infinity: thanks, I try that
[11:26] <menace> aeh, wait a minute, infinity. i use trusty with updates and it does not work for me... but i'll try your diff.gz anyway :)
[11:27] <menace> though i have libreoffice 4.2.3~rc3
[11:28] <bluesabre> sponsors, sru team, can we upload these items to -proposed to begin verification?
[11:28] <bluesabre> https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1331871
[11:28] <bluesabre> https://bugs.launchpad.net/ubuntu/trusty/+source/menulibre/+bug/1323405
[11:34] <infinity> TheMuso: I can merge it.
[12:20] <infinity> xnox: What was wrong with the xbmc upload 10 hours ago? :P
[12:42] <mlankhorst> does anyone want to sponsor https://mblankhorst.nl/etc/llvm-toolchain-3.4_3.4.2-3ubuntu1.debdiff for me? debdiff is against the debian version
[12:43] <mlankhorst> oh woops
[12:49] <xnox> infinity: lack of coffeine in my body? =)
[12:51] <cjwatson> brendand,mvo: sorry, I'm going to have to miss this call this week - I left a brief report in the calendar invite
[12:51] <brendand> cjwatson, np - thanks
[12:52] <mvo> cjwatson: no problem (from my side), thanks for the note
[12:52] <mvo> s
[12:58] <pitti> cjwatson: \o/ congrats for landing the image builds on buildds, really nice!
[13:11] <mlankhorst> oh fixed the build issue, https://mblankhorst.nl/etc/llvm-toolchain-3.4_3.4.2-3ubuntu1.debdiff
[13:15] <infinity> mlankhorst: Looking.
[13:18] <GunnarHj> Anybody in the SRU team who can take a look at bug 1308771? What makes it special is that the fix consists of two new binaries.
[13:20] <tseliot> bdmurray: hey, can you approve nvidia-prime in precise-proposed, please? It fits the same use cases of ubuntu-drivers-common
[13:25] <tseliot> bdmurray: actually, let's hold off, I might as well check a few oem details first while I'm at it
[13:26] <infinity> mlankhorst: You shouldn't have dropped the delta on patches/lldb-link-atomic.diff
[13:27] <mlankhorst> why's that?
[13:27] <mlankhorst> (it was conflicting, so i figured the debian one was more up to date)
[13:27] <infinity> mlankhorst: Did you look at the delta?  We just drop the conditional.
[13:28] <infinity> mlankhorst: The Debian one is still wrong, just slightly less wrong than it used to be.  Adjusting for the fuzz would have been the right thing.
[13:28] <mlankhorst> ok
[13:28] <mlankhorst> want me to redo it or?
[13:28] <infinity> Nah, I'll fix it.
[13:28] <mlankhorst> ok thanks
[13:29] <infinity> Just going through the rest of the review before I sponsor.
[13:34] <GunnarHj> bdmurray: ping?
[13:35] <ChrisTownsend> I'm prepping the next Unity SRU for Trusty and we would like to include a fix that has a new string.  What is the policy for handling this regarding localization/documentation/etc?
[13:35] <seb128> ChrisTownsend, "don't do that" would be the default response there ... what's the string/where is it going to be displayed?
[13:36] <ChrisTownsend> seb128: It's  a string in the lcokscreen telling the user the Caps lock is on.  Give me a sec and I'll give you the exact string.
[13:37] <seb128> ChrisTownsend, do you have a bug report about that/a screenshot?
[13:37] <infinity> ChrisTownsend: Like a hover text over the /!\ icon?
[13:38] <ChrisTownsend> seb128: I'll get that to you in a sec.  Trying to find the bug in my sea of open tabs.
[13:38] <ChrisTownsend> infinity: Yes
[13:38] <infinity> seb128: You can see it on utopic.  Ctrl-Alt-L, hit caps lock, hover over icon.
[13:39] <infinity> ChrisTownsend: Generally, the answer to new strings is "just don't", but since it's not visible except on hover, maybe the added functionality is worth the lack of translation.
[13:39] <infinity> ChrisTownsend: Though, if you could get some translations in too, that would be much better.
[13:39] <seb128> ChrisTownsend, what infinity said
[13:39] <seb128> having translations is doable
[13:39] <seb128> upload a new template to launchpad, which includes the string
[13:40] <seb128> wait for translators to work on it, and for a langpack export
[13:40] <seb128> then include the code change
[13:40] <infinity> Well, we'll spin new langpacks for 14.04.1 in a couple of weeks, probably.
[13:40] <seb128> we did it for the logout-when-other-users-are-connected dialog
[13:40] <infinity> So, if one can get it well-translated by then, that would be great.
[13:40] <seb128> right
[13:40] <seb128> launchpad shares strings between series I think
[13:41] <infinity> But, being a mouseover hover, I'm also not hugely put out by it being untranslated at first.
[13:41] <seb128> so it might already be translated in utopic and trusty should get those once the template is updated
[13:41] <seb128> yeah, same here
[13:41] <ChrisTownsend> infinity: So it's ok to go ahead and include the fix in our next SRU and let the translations catch up?
[13:41] <infinity> ChrisTownsend: Yeah, I think that's fine.
[13:41] <ChrisTownsend> infinity: Cool, thanks.
[13:42] <ChrisTownsend> seb128: Thanks to you too:)
[13:42] <seb128> ChrisTownsend, just make sure the string is included in the translation template
[13:42] <infinity> ChrisTownsend: But if you guys can follow up on the state of the string in LP and see what it'll look like for 14.04.1, that would be nice.
[13:42] <seb128> yw!
[13:42] <ChrisTownsend> seb128: Will do
[13:42] <ChrisTownsend> infinity: Ok
[13:42] <zyga> sergiusens: rsync works :)
[13:42] <zyga> sergiusens: I got a way to use rsync that works with the likes of phablet-shell
[13:42] <zyga> sergiusens: and it's x10 faster from what I see
[13:43] <zyga> sergiusens: I can show you the patches if you want to see
[13:43] <sergiusens> zyga: sure; sounds good
[13:43] <seb128> could somebody from the SRU team review libdbusmenu in the trusty queue? it's a simple diff and it has been there for a while, locking a landing silo
[13:44] <infinity> seb128: Ahh, yeah, now that the KDE stuff is all cleared out, I can read the queue again!
[13:44] <seb128> infinity, ;-)
[13:47] <infinity> mlankhorst: Uploading.
[13:47] <mlankhorst> ty
[13:50] <infinity> seb128: Accepted.
[13:50] <seb128> infinity, thanks
[14:06] <cjwatson> mvo: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-click/lastBuild/? \o/
[14:10] <mvo> cjwatson: yeah!
[14:11] <mvo> cjwatson: that looks great! I was wondering if something like https://code.launchpad.net/~mvo/cupstream2distro-config/click-tests-against-devel-branch/+merge/224140 would help us too, i.e. run the jenkins-bot on all MPs against lp:click/devel (it seems to be defaulting to lp:click currently)
[14:14] <menace> how can i recognize if a package is a virtual package? is there any way to see this in the control/apt-cache show part?
[14:15] <infinity> menace: If it's a virtual package, it doesn't exist.  That's sort of the point.
[14:16] <infinity> (base)adconrad@cthulhu:~$ apt-cache show mail-transport-agent
[14:16] <infinity> N: Can't select versions from package 'mail-transport-agent' as it is purely virtual
[14:16] <infinity> menace: ^-- As an example.
[14:16] <cjwatson> mvo: Ah, that sounds like it'd make sense
[14:17] <OdyX> tkamppeter: sorry, my cups-filters 1.0.54-2 upload had my local-non-committed-failing autopkgtests in it. I will upload an updated cups with the running script installed and then upload a new cups-filters with the filters activated or the tests removed.
[14:17] <infinity> mlankhorst: I'm cancelling your PPA builds of llvm to reclaim buildd resources, since that seems somewhat redundant with the distro upload.
[14:18] <menace> hrm, i'm updating packages in our distribution (based on ubuntu) in dak. and i already missed with the kernel-package and the ssh-package the concrete packages, because i just imported the virtual packages *headscratch*
[14:18] <mlankhorst> sure
[14:19] <xnox> menace: "imported the virtual packages" not sure that would be possible..... you possibly imported some package that is a provider of it. What are you trying to achieve, how & why? Maybe there is a better way to do it....
[14:19] <mlankhorst> oh the llvm-toolchain ftbfs for ppc64el seems to not be a new one
[14:19] <mlankhorst> goodie
[14:20] <infinity> mlankhorst: Yeah, it's been like that for a while.  We'll get it sorted at some point.
[14:22] <cjwatson> Riddell: For the opencv/arm64 failure, I think disabling precompiled headers on arm64 is the right fix for now - I've had to do that in a few other places
[14:22] <infinity> cjwatson: Do we know if that's fixed in gcc-4.9?
[14:22] <cjwatson> Not for sure
[14:22] <infinity> (And why it seems to have broken only in utopic...?)
[14:23] <infinity> Actually, hrm, I wonder if this spells doom for the gcc-4.8 microrelease SRU too.
[14:23] <menace> well, i want to update packages from precise to OurCodeName via dak. and it happened a few times, when i updated the linux meta-package, the the dependent packages would not be updated. and as far as i saw, this was because the meta-package is virtual or has a new name
[14:24] <infinity> menace: That doesn't sound like it has anything to do with virtual packages, just that you need to import both the "linux-meta" and "linux" source packages.
[14:24] <menace> something similar seemed to happen with the ssh package as well. i'm not very sure, how to work with dak correct with that issue..
[14:24] <menace> hrm
[14:25] <menace> i'll come back when i better understand my problems :)
[14:34] <bdmurray> GunnarHj: hello
[14:38] <Riddell> thanks cjwatson
[14:45] <xnox> menace: neither linux-meta nor linux are virtual. Simply each abi bump changes the binaries package names on the linux package, and the deps change name on linux-meta. If you import one without the other, your archive is inconsistent (you have packages depending on other packages, which are not present)
[14:45] <xnox> menace: apt has no idea if that's intended or a mistake, and it tells you that it doesn't know about it - maybe it's virtual?! (and no providers where found for it)
[14:47] <xnox> menace: but it cannot know, that the dak archive you created simply isn't in a consistent state and e.g. missing a matching copy of the linux package & binaries.
[14:53] <psusi> cjwatson: I hate to bother you with this but I can find zero documentation anywhere on it ( I'll have to write some once I figure it out ).. I am guessing that the grub-xen package is supposed to serve as the proper pv aware boot loader for xen domUs, but it doesn't seem to have a main binary anywhere that you can configure xen to load as the boot loader; it just installs the modules
[14:56] <cjwatson> psusi: It's a partial implementation that needs to be completed; https://lists.gnu.org/archive/html/grub-devel/2013-12/msg00184.html and thread has background
[14:56]  * infinity still uses this on precise, and wonders if he needs to learn new tricks for trusty: bootloader = '/usr/lib/xen-4.1/bin/pygrub'
[14:56] <smb> psusi, Using pygrub as bootloader should work for PV guests. It comes with the xen-utils. For trusty you may need to modify apparmor frofiles (libvirt)
[14:56] <cjwatson> psusi: The next stage at this point is to write up a boot protocol document that can be included in the Xen tree; I asked smb if he could help with this
[14:57] <smb> Or are we talking about efi variants?
[14:57] <cjwatson> psusi: It is *possible* to make grub-xen work, but it's not all assembled yet so documenting it would not be an appropriate next step
[14:57] <cjwatson> smb: pygrub2
[14:57] <cjwatson> smb: remember our conversation in Malta?
[14:57] <smb> cjwatson, We had one?
[14:57] <cjwatson> Yes
[14:57] <cjwatson> Anyway, the thread above has the background :)
[14:58] <smb> cjwatson, (you really had, with that guy that could not stand straight which was me?) Anyway ok
[14:58] <psusi> afaics, pygrub was a hack that externally parses the grub.cfg from outside the domU and figures out how to translate that into xen commands to launch the domU with the right kernel.. and this new grub-xen is supposed to be an actual build of grub that can run inside the domU and use the pv disk io etc to do everything grub normally does
[14:58] <cjwatson> smb: Hm, I guess maybe it was apw
[14:59] <cjwatson> All you kernel folks are indistinguishable after all
[14:59] <smb> psusi, Ah ok. There also is pvgrub buried in the xen source which works once one goes through the horrible setup path (involving downloading a lot of tar'ed libraries)
[15:00] <cjwatson> pvgrub is what grub-xen will replace once it's finished
[15:00] <cjwatson> a.k.a. PV-GRUB2
[15:00] <smb> cjwatson, Usually people confuse the Ste(ph|f)ane?'s :)
[15:00] <apw> cjwatson, erm, maybe, /me reads
[15:00] <infinity> smb: Big Steffie and Little Steffie, you mean.
[15:01] <smb> infinity, nope. really not
[15:01] <infinity> :)
[15:01]  * xnox wistles 2 1/2 man theme tune
[15:01] <smb> I may have cup size a but not feeling very feminine :-P
[15:01] <xnox> *whistles?!
[15:02] <smb> cjwatson, Ok, yeah. I guess I have to grab apw at some point
[15:02] <psusi> oh wait... grub-install maybe did make something... core.elf?
[15:03] <apw> cjwatson, oh yeah that might have been me :)
[15:04] <cjwatson> psusi: Don't expect any of this to work yet
[15:06] <menace> 3
[15:16] <caribou> is there a preferred way to build unit tests for bash scripts ?
[15:17] <pitti> caribou: I think shunit2 (package|program) is the de-facto standard, although many scripts just use some ad-hoc stuff like [ $a = "expected ]
[15:21] <caribou> pitti: ok I'll look into it, thanks
[15:22] <caribou> pitti: was looking at what I did in another live, was using PERL for testing bash..
[15:23] <caribou> pitti: matter of fact, those tests wil go to Debian forst
[15:23] <caribou> s/forst/first
[15:37] <slangasek> xnox: pfb2t1c2pfb? are you having a stroke?
[15:39] <xnox> slangasek: mostly hayfever.
[15:43]  * mdeslaur didn't know pfb2t1c2pfb was russian for 'Atchoo'
[15:44] <ogra_> bless you
[15:46] <slangasek> xnox: subscribed; but I wonder if I should put a moratorium on Foundations-owned MIRs to force the issue of archive reorg ;)
[15:49] <pitti> sil2100: FYI, libunity-scopes2 now fails to install in -proposed due to "GError: Can not find a single database provider in /etc/click/databases"; this fails the tests for ubuntu-system-settings-online-accounts and unity-scope-click and thus holds back stuff
[15:49] <pitti> ubuntu-system-settings-online-accounts and unity8 in particular
[15:49] <pitti> robru: ^ maybe you are interested as well
[15:51] <sil2100> pitti: oh...
[15:51] <seb128> sil2100, moved that to -touch
[15:51] <xnox> slangasek: https://launchpad.net/ubuntu/+source/moratorium does not exist.
[15:51] <seb128> since we don't have mhr3 here
[15:51] <pitti> sil2100: I'm not sure, are you interested in notifications like this, or is that just noise for you?
[15:53] <sil2100> pitti: I would appreciate info like this, especially that I'm slowly moving to +1 maintenance work :)
[15:53] <pitti> sil2100: ok
[16:00] <seb128> pitti, thanks for pointing the issue!
[16:00] <pitti> seb128: de rien
[16:22] <shadeslayer> ev: how long does it take between someone applying for e.u.c access and them being added to the group?
[17:24] <hallyn> stgraber: I don't know why i can't keep this straight...  Suggests does *not* get installed by default?  It's ok for something in main to Suggest something in multiverse?
[17:24] <hallyn> or it does and it's not?
[17:24] <cjwatson> Correct on both counts
[17:25] <hallyn> uh.  the first pair, not the second? :)
[17:26] <stgraber> hallyn: the first
[17:26] <hallyn> cool, thanks, then qemu can Suggest ovmf, dropping one bit of delta from debian - thx
[17:26] <stgraber> yep
[17:38] <ev> shadeslayer: as long as it takes for me to review it. Is there a specific user you're waiting on?
[17:38] <shadeslayer> ev: yeah, Marco Martin
[17:38] <ev> do be aware they have to provide an address and project information
[17:38]  * ev looks
[17:38] <ev> yeah, Marco hasn't provided an address
[17:38] <ev> he'll need to submit the form again with that part filled out
[17:39] <ev> frustratingly there doesn't appear to be a way to make those fields required, though I'd still have the problem of people writing N/A in them.
[17:40] <shadeslayer> heh
[17:41] <shadeslayer> ev: I've passed on the info to him, he's upstream KDE, useful to have them access to the tracker, instead of me copy pasting backtraces on pastebin :P
[17:41]  * ev nods
[17:41] <ev> happy to add him as soon as he gets the form completed
[17:41] <shadeslayer> cheers, and thx :)
[17:41] <ev> sounds like he'd be a great addition to the team :)
[17:41] <shadeslayer> *nod*
[17:43] <shadeslayer> ev: David Edmundson too :)
[17:48] <psusi> well once I remembered this old server I'm importing into a xen domU on new hardware was in fact 32 bit, and I used the 32 bit grub core.elf, it seems to work quite nicely... aside from the fact that the xen console does not seem to notify the domU about the terminal dimentions
[18:09] <hallyn> mvo: hi, would you mind taking a look at http://people.canonical.com/~serge/netcf-src-0.2.4-2/netcf_0.2.4-2.dsc and sponsoring into debian-experimental?  (debian/libnetcf1.symbols fixes suggested by xnox)
[18:41] <dobey> /usr/include/accounts-qt5/Accounts/service.h:38:24: fatal error: QDomDocument: No such file or directory #include <QDomDocument>
[18:41] <dobey> whee, so i guess qt5.3 broke libaccounts-qt5?
[19:31] <mdeslaur> what's going on with https://errors.ubuntu.com/ ?
[19:36] <sbeattie> bdmurray: ^
[19:38] <bdmurray> its not accepting core dumps at the moment, I'm actively working on it
[19:38] <mdeslaur> bdmurray: darn, I was kind of hoping we had fixed every single bug :(
[19:38] <mdeslaur> ;)
[19:40] <bdmurray> yeah, that'd be neat
[20:17] <ChrisTownsend> infinity: Hey, you're the SRU guy today, right?
[20:35] <ari-tczew> can someone finally to sponsor one sync? bug 1327934
[20:36] <Unit193> Just one sync?  What about others' uploads? :(
[20:38] <ari-tczew> dunno
[20:39] <Unit193> ari-tczew: Just pulling your leg. ;)
[21:15] <ari-tczew> Unit193: tomorrow as patch pilot is xnox, looks good :P
[21:23] <Unit193> Heh. :)
[21:30] <brendand> lifeless, hi - i have something working for testtools, but i'm just worried i'll break something. unit tests still pass, but can you have a quick look at it?
[21:32] <brendand> lifeless, http://paste.ubuntu.com/7692320/
[23:14] <sarnold> is there an easy way to pull the build logs for all 'released' versions of a package from launchpad?