[00:17] <shadeslayer> xnox: ping
[00:18] <shadeslayer> xnox: did you have a look at that cmake patch?
[05:03] <Logan> wgrant: yo, around to field a UDD question?
[05:04] <wgrant> Logan: Hi
[05:04] <Logan> hey
[05:04] <Logan> so there are a ton of packages that failed with 403s
[05:05] <Logan> do they need requeues?
[05:05] <wgrant> Damn, someone noticed.
[05:05] <Logan> :P
[05:05] <wgrant> I was hoping we could leave it broken and it would slowly fade away into oblivion.
[05:05] <wgrant> Is it actually useful to you?
[05:05] <Logan> I sent a message to the list and filed a bug a few days ago
[05:05] <Logan> UDD is only useful for me in terms of doing merges
[05:06] <Logan> because I don't like MoM
[05:06] <Logan> and I prefer a VCS workflow for merging
[05:06] <Logan> I know Robie posted his git workflow to the list, but it's a bit convoluted
[05:06] <wgrant> I also prefer a VCS workflow, but I prefer one that works for most packages more :)
[05:07] <Logan> with MoM, it's not easy to diff against Debian
[05:07] <Logan> also, it leaves patches in a weird state in my experience
[05:07] <Logan> for example, I just tried to merge cinnamon using MoM, and it was a mess
[05:09] <Logan> if you try it, you'll see what I mean
[05:18] <wgrant> 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] <wgrant> Logan: Fixed.
[05:18] <Logan> cheers
[05:19] <Logan> just 27963 to go ;)
[05:20] <Logan> if I can get access to the box, I can try fixing up the import failures
[05:20] <Logan> but as far as I can remember, only Canonical employees can do that
[05:21] <wgrant> 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] <wgrant> We thoroughly discourage its use.
[05:21] <Logan> and the recommended alternative is MoM for merging?
[05:22] <Logan> because the packaging guide currently advocated for UDD-based development
[05:22] <wgrant> Correct.
[05:22] <wgrant> Yes, the packaging guide is... misguided.
[05:22] <Logan> is there work on Git-based UDD?
[05:22] <Logan> if so, can I help?
[05:22] <wgrant> 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] <wgrant> We haven't started on Git-based UDD, specifically. But it's something we are investigating.
[05:23] <Logan> ok
[05:23] <wgrant> The current vague plan is that we'll improve dgit to meet Ubuntu's needs.
[05:23] <wgrant> But that's by no means set in stone.
[05:23] <Logan> also, I'm wondering if you could shed some light on the future of packaging
[05:23] <wgrant> I'd really like to solve the 3.0 (quilt) problem, but that's Very Hard™.
[05:23] <Logan> because I'm a bit confused by how DEBs and snappy will go together
[05:24] <Logan> like, will there still be a role for MOTUs?
[05:25] <wgrant> Deb-based systems will exist for the forseeable future, but I don't know of any detailed roadmap.
[05:25] <Logan> and how will we go about merging from Debian and stuff?
[05:25] <Logan> hmm, alright
[05:25] <wgrant> For example, developer desktops can't exactly use snappy in the way that a phone does.
[05:26] <wgrant> And snaps have to be built from something -- in a lot of cases they'll probably be built from debs.
[05:26] <wgrant> I'm not completely up to date with the latest snappy plans.
[05:26] <Logan> ok, thanks for shedding some light
[05:26] <Logan> I wish there would be more communication from Canonical to Ubuntu community devs
[14:49] <linux_hacker> ,What features do you think Ubuntu 15.10 will have upon release?
[17:22] <ari-tczew> micahg: ping
[17:56] <ari-tczew> 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] <ari-tczew> 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] <ari-tczew> GL & HF.
[23:23] <sergio-br222> hi
[23:25] <sergio-br222> I'm trying to understand why there's libqt5opengl5-gles-dev in utopic and up
[23:26] <sergio-br222> in trusty I was using libqt5opengl5-dev to build ppsspp for ARM, do I need this GLES version on utopic and vivid?
[23:28] <sergio-br222> debian 8 does not has this package (and others GLES as well), so it's little confuse
[23:28] <RAOF> 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] <sergio-br222> hum, but why trusty and debian does not have it?
[23:29] <RAOF> Because they didn't care about GLES? :)
[23:29] <sergio-br222> but it works
[23:29] <RAOF> Alternatively, if you don't mind depending on a mesa implementation detail, you can use GLES from the desktop version :)
[23:30] <sergio-br222> hum, so I can use libqt5opengl5-dev for GLES support, in vivid for example?
[23:31] <sergio-br222> I came here because I have no idea what to do with these deps, for vivid, in my PPA
[23:32] <RAOF> 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] <sergio-br222> I use GLES, in my odroid U3 board
[23:32] <RAOF> (Particularly: GLES support from the binary drivers is really new)
[23:32] <sergio-br222> it uses Mali
[23:33] <RAOF> Build against the GLES version; that's guaranteed to be not-incorrect ;)
[23:33] <sergio-br222> ok
[23:33] <sergio-br222> so I'll need to fork the debian folder to these new ubuntu versions
[23:33] <RAOF> ...Yeah, probably.
[23:34] <sergio-br222> but it's weird why ubuntu do this, and debian doesn't
[23:35] <RAOF> Debian doesn't have to care about GLES-only hardware.
[23:35] <RAOF> Mostly.
[23:44] <sergio-br222> wait, these GLES packages, there's only for amd64 and i386 ?
[23:44] <sergio-br222> http://packages.ubuntu.com/vivid/libqt5opengl5-gles-dev
[23:47] <RAOF> Hm, wait?
[23:48] <RAOF> sergio-br222: Ah, right. My mistake, sorry.
[23:49] <sergio-br222> dunno if this page shows armhf package
[23:50] <RAOF> 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] <RAOF> 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] <sergio-br222> not sure if I understood
[23:52] <RAOF> 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] <sergio-br222> ahh
[23:53] <sergio-br222> so these gles packages are for cross compile?
[23:53] <RAOF> No; they're for use in the android emulator.
[23:53] <RAOF> Although I guess you could use them for cross-compile, too, now that you mention it.