[00:21] <lfaraone> Is there any real restriction beyond "we can distribute the binary legally" with software in multiverse? Can binary-only software be distributed this way?
[00:36] <JanC> lfaraone: as long as there are no restrictions about distributing and (very important!) redistributing, that's the only restrictions AFAIK
[00:38] <JanC> for example Adobe's flash plugin doesn't allow re-distribution, so it can't go into multiverse as is
[01:17] <lfaraone> JanC: okay. how do we evaluate SRUs for binary-only software in multiverse? If upstream or someone with access to the source provides a new binary, we can't audit that they followed the SRU criteria, right?
[01:24] <JanC> lfaraone: I suppose you'd have to rely on their word, which is exactly why open source software is preferred...
[01:25] <JanC> and I have no idea if there is any official process for that currently
[01:32] <lfaraone> JanC: okay, thanks.
[03:57] <paultag> Hey MOTU. I'm looking to practice debian-izing a small app that I wrote. It's in python. What should I be doing to make my debianizing life easy down the road ( only thing I can think of is build system, but I'm sure there is more )
[03:58] <paultag> and by debianizing, I mean rolling it into a .deb, this is Ubuntu only ( a small app for an Ubuntu team )
[03:58] <paultag> not that that matters :)
[04:14] <paultag> Anyone? Bueller?
[04:25] <micahg> paultag: are you packaging for the archive or for your own use?
[04:25] <paultag> micahg, PPA, I am not going to be guidelines strict. I get a lot of that upstream
[04:26] <micahg> paultag: ok, then we have a special channel for that: #ubuntu-packaging, but being the weekend, idk who's around, so patience is suggested
[04:26] <paultag> micahg, I don't quit freenode often :)
[04:26] <paultag> micahg, thanks :)
[04:26] <micahg> paultag: np
[08:01] <fabrice_sp> Hi. atlas is FTBFS because "Warning: In order to build Atlas under i386, you need the CPU extension sse3 available on your CPU"
[08:01] <fabrice_sp> is there any buildds that have sse3 capability?
[08:02] <fabrice_sp> or they are all virtualized?
[08:02] <tumbleweed> fabrice_sp: ran atlas on armel all night. It still loops
[08:02] <fabrice_sp> tumbleweed, thanks for trying :-)
[08:02] <tumbleweed> np
[08:02] <fabrice_sp> what is strange is that is doesn't seem to loop on Debian :-/
[08:03] <fabrice_sp> bug in compiler?
[08:03] <tumbleweed> dunno, can't see anything obvious. But I'm off hiking this morning - will have a look later
[08:06] <fabrice_sp> good hiking then :-)
[10:58] <BlackZ> fabrice_sp: openturns merge finished, I'm building it right now
[10:59] <arand> Can the debian packaging be GPLv3 when something that is packaged (e.g. images sounds) are under a "only along with this software and no modification"-type of license?
[11:04] <BlackZ> arand: just specify in the debian/copyright file other licenses of the software
[11:04] <BlackZ> specifying the files
[11:07] <arand> Yea, There's a whole tonne of them, since there's different contributors etc.
[11:07] <arand> So the GPL only applies to the debian/ folder, regardless of what is packaged then?
[11:08] <BlackZ> arand: yes, and the other files with the GPL license applied
[11:09] <BlackZ> arand: you can follow http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135
[11:12] <arand> Oh, that's something to delve into alright..
[12:40] <EricBa> Please could someone revu my package at http://revu.ubuntuwire.com/details.py?package=cortina
[12:41] <EricBa> i ment review
[12:46] <EricBa> hier kriegt man nie ne antwort oder?
[12:49] <geser> EricBa: most people are idle, especially on weekends. And to find reviewers is at all times hard.
[12:50] <EricBa> i tried many times befor
[12:50] <EricBa> many days
[12:52] <geser> you are not the only person who has trouble to find a reviewer as only a few MOTUs do reviews
[12:57] <fabrice_sp> EricBa, I'll have a look
[12:57] <fabrice_sp> but I see 6 uploads a day, I don't know if it's still stable enough
[12:58] <BlackZ> fabrice_sp: merge of openturns finished bug #593284 it builds!
[12:58] <fabrice_sp> BlackZ, cool: I'll have a look later (I'm processing the sponsoring queue)
[12:58] <fabrice_sp> thanks ;-)
[12:59] <fabrice_sp> EricBa, here?
[12:59] <BlackZ> fabrice_sp: if you don't want to build it, http://launchpadlibrarian.net/50262430/buildlog_ubuntu-maverick-i386.openturns_0.13.2-4ubuntu1~maverick1_FULLYBUILT.txt.gz
[12:59] <BlackZ> the build will take around 1 hr
[13:00] <fabrice_sp> I know :-/
[13:00] <EricBa> yes
[13:00] <fabrice_sp> I always build locally, to check the resulting deb file
[13:00] <fabrice_sp> why are all dependency with versions?
[13:01] <fabrice_sp> it will make harder backporting, excp if mandatory
[13:01] <EricBa> it needs that version
[13:03] <EricBa> ok pkg-config and dbus dont need a version
[13:04] <BlackZ> fabrice_sp: so you will build it locally ?
[13:04] <fabrice_sp> sorry: have to go. Will check later
[13:04] <fabrice_sp> BlackZ, yes
[17:34] <ScottK> fabrice_sp: Even for i686 you can't assume sse2, so something needs to be done run time to detect if sse2 is present or not and not use it if it isn't.
[17:47] <fabrice_sp> ScottK, so what would be the fix for atlas in i386?
[17:48] <fabrice_sp> I can desactivate the detection of sse3, but I'm not sure the package will be usable
[17:48] <fabrice_sp> it compiles fine in amd64
[17:51] <tumbleweed> Automatically Tuned Linear Algebra Software - that says it all :/
[17:51] <tumbleweed> fabrice_sp: I've been looking at the armel build log, I'm not convinced that it wouldn't have eventually finished
[17:51] <fabrice_sp> so just slowness?
[17:51] <tumbleweed> very very slow. It keeps tuning things until it's happy, as far as I can tell
[17:52] <jpds> The arms are slow.
[17:52]  * tumbleweed is trying another build - a few days this time...
[17:52] <tumbleweed> jpds: I gave it about 8 hrs
[17:54] <fabrice_sp> I've desactivated it in the last upload, so until someone complains that there is no armel build of atlas, it will stay that way
[17:54] <fabrice_sp> the worst part is that the i386 build failed because of missing sse3 instruction in the buildds...
[17:56] <fabrice_sp> so right now, atlas is broken
[17:56] <tumbleweed> hmm: from debian's build logs:
[17:56] <tumbleweed> Build needed 42:20:15, 216776k disc space
[17:56] <fabrice_sp> 42 hours?! not too bad :-)
[17:56] <tumbleweed> that'll be on real hardware though, probably a lot faster (and doesn't segfault like qemu)
[17:57] <fabrice_sp> the armel buildds in Ubuntu are real hardware or qemu?
[17:57]  * tumbleweed was going to ask the same thing
[17:57] <fabrice_sp> :-)
[17:58] <BlackZ> fabrice_sp: Warning: In order to build Atlas under i386, you need the CPU extension sse3 available on your CPU
[17:58] <BlackZ> are you afraid to enable it?
[17:58] <tumbleweed> BlackZ: we can't require sse3 on i386
[17:58] <fabrice_sp> BlackZ, and this is in the buildds, not in my computer ;-)
[17:59] <jpds> fabrice_sp: Real hardware.
[17:59] <fabrice_sp> BlackZ, it's detected with cpuinfo
[17:59] <fabrice_sp> jpds, thx
[17:59] <BlackZ> fabrice_sp: ahhh, hmm ...
[18:01] <tumbleweed> fabrice_sp: oh you mean it needs sse3 for building a version that doesn't require sse3?
[18:01] <fabrice_sp> tumbleweed, not sure about not requiringsse3 to run, but build requires it
[18:01] <fabrice_sp> I have to disable the sse3 detection, and upload to a ppa, to test
[18:03] <fabrice_sp> BlackZ, your comment in Bug 589120 means that it can be a sync?
[18:04] <BlackZ> fabrice_sp: no, there's another change
[18:04] <fabrice_sp> ok: I've seen so many nug reports this afternoon that I don't remember each of them :-)
[18:05] <BlackZ> fabrice_sp: check in the changelog file
[18:05] <fabrice_sp> ok
[18:06] <fabrice_sp> about atlas: it build sse3 packages: libatlas3gf-sse3
[18:08] <tumbleweed> ah right. and it probably wants to test them so it can tune
[18:08] <fabrice_sp> exactly
[18:08] <tumbleweed> time for canonical to upgrade the buildd farm :)
[18:08] <fabrice_sp> hmm, my guess is that I will desactivate the optimized version :-D
[18:10] <jpds> tumbleweed: There's no better armel hardware to upgrade to.
[18:10] <tumbleweed> jpds: no I mean sse3
[18:10]  * jpds looks at wikipedia.
[18:21] <ScottK> fabrice_sp: sse2 detection needs to be done at run time.
[18:21] <ScottK> I'm not sure what needs to be done to achieve that.
[18:28] <tumbleweed> ScottK: this is for a -sse3 package
[18:28] <ScottK> Oh.
[18:28] <ScottK> Ignore me then.
[18:36]  * fabrice_sp has just uploaded a package that deltes all sse3 packages and 'downgrade' builds to sse2
[18:38] <fabrice_sp> BlackZ, why the second hcnage is still required?
[18:39] <fabrice_sp> IIRC, -DGTK_DISABLE_DEPRECATED is used to avoid error on deprecated methods
[18:40] <fabrice_sp> anyone can confirm that?
[18:41] <BlackZ> fabrice_sp: I think to allow to package
[18:41] <BlackZ> why drop it?
[18:47] <fabrice_sp> It seems that the comment is broken :-)
[18:48] <fabrice_sp> BlackZ, and this would allow us to sync the package ;-)
[18:48] <fabrice_sp> no bug is referenced, so it's hard to find why it has been changed
[18:48] <BlackZ> fabrice_sp: then feel free to rename the bug and delete the patch
[18:49] <BlackZ> I can't right now
[18:49] <fabrice_sp> if I were sure, I would have done it already :-)
[18:50] <fabrice_sp> I'll try to build 0.2.8-1ubuntu1 in lucid, to see if it FTBFS
[18:55] <fabrice_sp> BlackZ, 0.2.8-1ubuntu1 FTBFS in lucid, so that would explain the fix
[18:55] <fabrice_sp> I'll convert the bug to a sync request and ack it
[19:08] <dupondje> If something is ftbfs on armel, can we somewhere retry to build it to see if it build now ?
[19:08] <tumbleweed> dupondje: on your own qemu
[19:09] <dupondje> no other way ?
[19:09]  * tumbleweed has one set up if you want me to test for you
[19:09] <dupondje> https://launchpad.net/ubuntu/+source/loop-aes-utils/2.16.2-1/+build/1764607 => is quit a strange error :s
[19:10] <tumbleweed> that looks like a compiler bug
[19:11] <dupondje> gcc is upgraded
[19:11] <dupondje> so maby it works now
[19:11] <tumbleweed> ok, I'll test
[19:18] <tumbleweed> yay, qemu segfault :)
[19:19] <dupondje> lol
[19:20] <tumbleweed> dupondje: building (it probably won't segfault again until its done)
[19:21] <dupondje> what was wrong ? :)
[19:21] <tumbleweed> IO seems to cause it. it aften segfaults soon after running aptitude
[19:23] <dupondje> I hate it when merges reported are lagging :)
[19:23] <dupondje> accept them :D
[19:40] <dupondje> its still building ? ;)
[19:40] <dupondje> https://merges.ubuntu.com/universe.html => what are the different colors btw ? :)
[19:40] <tumbleweed> dupondje: yes, it's slow
[19:41] <tumbleweed> hah. I had to read the source to answer that for myself
[19:41] <tumbleweed> the colours are for debian priorities
[19:41] <tumbleweed> it really should say at the top "ordered by by priority"
[19:50] <tumbleweed> dupondje: same build error
[19:53] <dupondje> crap :(
[20:24] <anoteng> I'd like a review of http://revu.ubuntuwire.com/p/transgui . This is an application I and many others use daily, and I'd like to see it included in Ubuntu. I'm sure the pro's will find a lot of things for me to fix in the package… bug #332067
[20:35] <fabrice_sp> anoteng, version should be 0ubuntu1, target maverick
[20:36] <fabrice_sp> run update-maintainer to use latest value for maintainer
[20:36] <Rhonda> Alright. wesnoth-1.8 v 1.8.2 hit lenny-backports earlier than wesnoth-1.8 v 1.8 did hit karmic-backports.  %-)
[20:45] <arand> Is it possible to manage binary changes in the diff.gz? e.g. I'm adding an image, am I needed to stick it in the .orig.? (I'm not packaging with policy in mind..)
[20:50] <Rhonda> arand: With source format 3.0 (quilt) it's possible to manage binary changes.
[20:50] <Rhonda> Because it will be .debian.tar.gz instead of .diff.gz
[20:52] <arand> Ah, ok, I'm not using 3.0 then I guess.. Well making an .xpm of the image works as my quickfix :/
[20:52] <tumbleweed> arand: that are base64
[20:52] <tumbleweed> or
[21:19] <BlackZ> fabrice_sp: could you look at bug #593416 ?
[21:21] <fabrice_sp> BlackZ, strange enough: there is no qemu in maverick :-/
[21:22] <fabrice_sp> from karmic: Deleted in karmic-release on 2009-09-24  (Reason: merged into qemu-kvm,
[21:24] <BlackZ> hmm, but it provides the 'qemu' package
[21:24] <BlackZ> (seems the old one)
[21:24] <fabrice_sp> so sorry: it seems that you worked on a dead-end merge
[21:24] <fabrice_sp> yeah: the qemu package is the old one
[21:24] <BlackZ> ok, marking as invalid
[21:24] <fabrice_sp> seems so
[21:24] <BlackZ> please, unsubrscribe U-S
[21:25] <fabrice_sp> I found strange qemu in universe
[21:25] <fabrice_sp> done
[21:28] <BlackZ> fabrice_sp: so you could look at bug #590158 :P
[21:31]  * fabrice_sp hates merges from -0ubuntu1 versions :-)
[21:32] <fabrice_sp> I'll have a look tomorrow :-)
[21:33] <BlackZ> heh thanks fabrice_sp !
[21:33] <fabrice_sp> yw!
[21:33] <fabrice_sp> thanks to you to work on that!
[21:33] <fabrice_sp> really