[00:17] xnox: ping [00:18] xnox: did you have a look at that cmake patch? === kitterma is now known as ScottK === sidi is now known as Guest7975 === xnox_ is now known as xnox === neunon_ is now known as neunon === tumbleweed_ is now known as tumbleweed === stokachu_ is now known as stokachu === \b is now known as benonsoftware === plars_ is now known as plars === wgrant_ is now known as wgrant === Ursinha_ is now known as Ursinha === StevenK is now known as Guest30715 === pitti is now known as Guest47071 === ryanakca is now known as Guest16385 === Adri2000 is now known as Guest65993 === elijah is now known as Guest16052 === happyaron is now known as Guest24531 === jpds is now known as Guest71062 === sidi_ is now known as Guest17378 === lynxman_ is now known as lynxman === mchro- is now known as mchro === lifeless1 is now known as lifeless === Guest30715 is now known as StevenK === tjaalton_ is now known as tjaalton [05:03] wgrant: yo, around to field a UDD question? [05:04] Logan: Hi [05:04] hey [05:04] so there are a ton of packages that failed with 403s [05:05] do they need requeues? [05:05] Damn, someone noticed. [05:05] :P [05:05] I was hoping we could leave it broken and it would slowly fade away into oblivion. [05:05] Is it actually useful to you? [05:05] I sent a message to the list and filed a bug a few days ago [05:05] UDD is only useful for me in terms of doing merges [05:06] because I don't like MoM [05:06] and I prefer a VCS workflow for merging [05:06] I know Robie posted his git workflow to the list, but it's a bit convoluted [05:06] I also prefer a VCS workflow, but I prefer one that works for most packages more :) [05:07] with MoM, it's not easy to diff against Debian [05:07] also, it leaves patches in a weird state in my experience [05:07] for example, I just tried to merge cinnamon using MoM, and it was a mess [05:09] if you try it, you'll see what I mean [05:18] 276.942 Imported [PackageToImport(cinnamon, 2.6.7-2, debian, sid, release, ), PackageToImport(cinnamon, 2.6.7-3, debian, sid, release, ), PackageToImport(cinnamon, 2.6.7-3, debian, stretch, release, ), PackageToImport(cinnamon, 2.6.8-1, debian, sid, release, )] [05:18] Logan: Fixed. [05:18] cheers [05:19] just 27963 to go ;) [05:20] if I can get access to the box, I can try fixing up the import failures [05:20] but as far as I can remember, only Canonical employees can do that [05:21] Bazaar-based UDD is on life support. We're not putting effort into fixing it, as it's extremely fragile and simply cannot work for many interesting packages. [05:21] We thoroughly discourage its use. [05:21] and the recommended alternative is MoM for merging? [05:22] because the packaging guide currently advocated for UDD-based development [05:22] Correct. [05:22] Yes, the packaging guide is... misguided. [05:22] is there work on Git-based UDD? [05:22] if so, can I help? [05:22] UDD has never worked reliably for all packages, so it was a somewhat odd choice to default to it in the packaging guide. [05:23] We haven't started on Git-based UDD, specifically. But it's something we are investigating. [05:23] ok [05:23] The current vague plan is that we'll improve dgit to meet Ubuntu's needs. [05:23] But that's by no means set in stone. [05:23] also, I'm wondering if you could shed some light on the future of packaging [05:23] I'd really like to solve the 3.0 (quilt) problem, but that's Very Hard™. [05:23] because I'm a bit confused by how DEBs and snappy will go together [05:24] like, will there still be a role for MOTUs? [05:25] Deb-based systems will exist for the forseeable future, but I don't know of any detailed roadmap. [05:25] and how will we go about merging from Debian and stuff? [05:25] hmm, alright [05:25] For example, developer desktops can't exactly use snappy in the way that a phone does. [05:26] And snaps have to be built from something -- in a lot of cases they'll probably be built from debs. [05:26] I'm not completely up to date with the latest snappy plans. [05:26] ok, thanks for shedding some light [05:26] I wish there would be more communication from Canonical to Ubuntu community devs === TheMaster is now known as Unit193 === Guest24531 is now known as happyaron === mwhudson_ is now known as mwhudson === mwhudson is now known as Guest80728 === mwhudson is now known as mwhudson__ === mwhudson__ is now known as mwhudson === dkessel_ is now known as dkessel === athairus is now known as athairuzzz === debfx_ is now known as debfx === lan3y is now known as Laney === Laney is now known as Guest38885 === Guest38885 is now known as Laney === enrico_ is now known as enrico === maxb_ is now known as maxb === yp is now known as ypwong === czchen_ is now known as czchen === Tribaal_ is now known as Tribaal === ming is now known as Guest65399 === sidi is now known as Guest16893 === sidi_ is now known as Guest24523 === DalekSec_ is now known as DalekSec [14:49] ,What features do you think Ubuntu 15.10 will have upon release? === juliank0 is now known as juliank === work_alkisg is now known as alkisg === sidi is now known as Guest13575 === ochosi_ is now known as ochosi === dobey_ is now known as dobey === bduncan_ is now known as bduncan === s1aden is now known as sladen [17:22] micahg: ping [17:56] micahg: I just took a look on merging blueman and noticed that there is obexd 0.47 needed, wich is not at the moment in our archive reachable. [17:59] Maybe you know already, I was trying to merge obexd more than 1,5 years ago, but without result. More info on bug 1263260. [17:59] bug 1263260 in obexd (Ubuntu) "Merge obexd 0.48-2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1263260 [17:59] GL & HF. [23:23] hi === sergiusens_ is now known as sergiusens [23:25] I'm trying to understand why there's libqt5opengl5-gles-dev in utopic and up [23:26] in trusty I was using libqt5opengl5-dev to build ppsspp for ARM, do I need this GLES version on utopic and vivid? [23:28] debian 8 does not has this package (and others GLES as well), so it's little confuse [23:28] sergio-br222: That's a build against GLES rather than desktop GL; if you want to use GLES rather than desktop GL, you'll need to use that one. [23:29] hum, but why trusty and debian does not have it? [23:29] Because they didn't care about GLES? :) [23:29] but it works [23:29] Alternatively, if you don't mind depending on a mesa implementation detail, you can use GLES from the desktop version :) [23:30] hum, so I can use libqt5opengl5-dev for GLES support, in vivid for example? [23:31] I came here because I have no idea what to do with these deps, for vivid, in my PPA [23:32] Do you use GLES? If so, you should probably be building against the GLES headers (and you won't work reliably work on the desktop, because GLES doesn't work reliably on the desktop). [23:32] I use GLES, in my odroid U3 board [23:32] (Particularly: GLES support from the binary drivers is really new) [23:32] it uses Mali [23:33] Build against the GLES version; that's guaranteed to be not-incorrect ;) [23:33] ok [23:33] so I'll need to fork the debian folder to these new ubuntu versions [23:33] ...Yeah, probably. [23:34] but it's weird why ubuntu do this, and debian doesn't [23:35] Debian doesn't have to care about GLES-only hardware. [23:35] Mostly. [23:44] wait, these GLES packages, there's only for amd64 and i386 ? [23:44] http://packages.ubuntu.com/vivid/libqt5opengl5-gles-dev [23:47] Hm, wait? [23:48] sergio-br222: Ah, right. My mistake, sorry. [23:49] dunno if this page shows armhf package [23:50] sergio-br222: The qt5opengl packages *are* built for GLES on armhf and desktop GL on x86. The problem that the -opengl-gles packages are solving are that the android emulator is (a) x86 and (b) only supports GLES. [23:51] sergio-br222: So the *correct* answer is ‘just use the opengl5-dev packages, and know that if you care about !armhf you'll need to conditionally use GL/GLES depending on build arch’. [23:51] not sure if I understood [23:52] sergio-br222: We use Qt on the phone, which uses android kernelspace, so we need a build that works in the android emulator, which is x86 but has no desktop GL support. So we need to build Qt twice for x86 - once with desktop GL, once with GLES. [23:53] ahh [23:53] so these gles packages are for cross compile? [23:53] No; they're for use in the android emulator. [23:53] Although I guess you could use them for cross-compile, too, now that you mention it. === StevenK_ is now known as StevenK === StevenK is now known as Guest72529 === Guest72529 is now known as StevenK